At 04:41 AM 6/10/2003 -0700, William Lee Irwin III wrote:

At 02:20 AM 6/10/2003 -0700, William Lee Irwin III wrote:

quoted

quoted

Mike, any chance you can turn your series of patches into one that
applies atop mingo's intra-timeslice priority preemption patch? If
not, I suppose someone else could.

On Tue, Jun 10, 2003 at 01:31:32PM +0200, Mike Galbraith wrote:

quoted

I've never seen it.  Is this the test-starve fix I heard mentioned on lkml
once?

No idea what the posted name was. What it does is obvious enough. It
was posted earlier in this thread.


At 02:20 AM 6/10/2003 -0700, William Lee Irwin III wrote:

quoted

quoted

There also appears to be some kind of issue with using monotonic_clock()
with timer_pit as well as some locking overhead concerns. Something
should probably be done about those things before trying to merge the
fine-grained time accounting patch.

On Tue, Jun 10, 2003 at 01:31:32PM +0200, Mike Galbraith wrote:

quoted

Ingo had me measure impact with lat_ctx, and it wasn't very encouraging
(and my box is UP).  I'm not sure that I wasn't seeing some cache effects
though, because the numbers jumped around quite a bit.  Per Ingo, the
sequence lock change will greatly improve scalability.  Doing anything
extra in that path is going to cost some pain though, so I'm trying to

Okay, so mitigating the hit to context switch is ongoing.

If it's used, seems some work will be required to measure the true (and 
practical) impact.

On Tue, Jun 10, 2003 at 01:31:32PM +0200, Mike Galbraith wrote:

quoted

figure out a way to do something ~similar.  (ala perfect is the enemy of
good mantra).

\vomit{Next you'll be telling me worse is better.}

That's an unearned criticism.

Timeslice management is currently an approximation.  IFF the approximation 
is good enough, it will/must out perform pedantic bean-counting.  Current 
timeslice management apparently isn't quite good enough, so I'm trying to 
find a way to increase it's informational content without the (in general 
case useless) overhead of attempted perfection.  I'm failing miserably btw ;-)

On Tue, Jun 10, 2003 at 01:31:32PM +0200, Mike Galbraith wrote:

quoted

wrt pit, yeah, that diff won't work if you don't have a tsc.  If something
like it were used, it'd have to have ifdefs to continue using
jiffies.  (the other option being only presentable on April 1:)

The issue is the driver returning garbage; not having as good of
precision from hardware is no fault of the method. I'd say timer_pit
should just return jiffies converted to nanoseconds.

That's the option that I figured was April 1 material, because of the 
missing precision.  If it could be made (somehow that I don't understand) 
to produce a reasonable approximation of a high resolution clock, sure.

Also, I posted the "thud" fix earlier in this thread in addition to the
monotonic_clock() bits. AFAICT it mitigates (or perhaps even fixes) an
infinite priority escalation scenario.

(yes, mitigates... maybe cures with round down, not really sure)

Couple that change with reintroduction of backboost to offset some of it's 
other effects and a serious reduction of CHILD_PENALTY and you'll have a 
very snappy desktop.  However, there is another side of the 
equation.  Large instantaneous variance in sleep_avg/prio also enables the 
scheduler to react quickly such that tasks which were delayed for whatever 
reason rapidly get a chance collect their ticks and catch up.  It can and 
does cause perceived unfairness... which is in reality quite fair.  It's 
horrible for short period concurrency, but great for long period 
throughput.  AFAIKT, it's a hard problem.

         -Mike 

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>