Re: 2.5.70-mm6

[Mike Galbraith]

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:
> >> 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:
> > 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:
> >> 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:
> > 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:
> > 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:
> > 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