Re: 2.5.70-mm6

[William Lee Irwin III]

At 04:41 AM 6/10/2003 -0700, William Lee Irwin III wrote:
>> \vomit{Next you'll be telling me worse is better.}

On Tue, Jun 10, 2003 at 08:53:51PM +0200, Mike Galbraith wrote:
> 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 
> ;-)

The criticism was of the maxim invoked, not the specific direction
you're hacking in.

At 04:41 AM 6/10/2003 -0700, William Lee Irwin III wrote:
>> 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.

On Tue, Jun 10, 2003 at 08:53:51PM +0200, Mike Galbraith wrote:
> 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.

If there's a TSC, it can be used for extra interpolation. But I think
timer_tsc already does that. I don't think it's quite so laughable; the
machines missing reliable time sources are truly crippled in some way,
by obsolescence or misdesign. I wouldn't call this a deficit. The
major platforms will do fine, and the rest will do no worse than now
apart from perhaps some function call and arithmetic overhead.

At 04:41 AM 6/10/2003 -0700, William Lee Irwin III wrote:
>> 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.

On Tue, Jun 10, 2003 at 08:53:51PM +0200, Mike Galbraith wrote:
> (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.

I don't know that there are answers better than mitigation.

I propose we err on the other side of the fence and back off as cases
where the larger instantaneous variances are more clearly needed arise.

-- wli