(sorry for the duplicate Ingo, this time I managed to Repy to All)

On Sat, 2007-03-17 at 08:45 +0100, Ingo Molnar wrote:
> * Nicholas Miell <[EMAIL PROTECTED]> wrote:
> 
> > The X people have plans for how to go about fixing this, [...]
> 
> then we'll first have wait for those X changes to at least be done in a 
> minimal manner so that they can be tested for real with RSDL. (is it 
> _really_ due to that? Or will X regress forever once we switch to RSDL?)

Yes, it's an X problem.

There's two issues, really -- smooth pointer movement or the lack
thereof and the servicing of clients at varying priorities. There's
vague plans floating around about moving all input processing off into a
separate high-priority thread and pretty much no ideas how to deal with
mixed priority clients.

So, the current scheduler works around this brain damage using
heuristics that sort of do the job and sometimes screw things up.

> We cannot regress the scheduling of a workload as important as "X mixed 
> with CPU-intense tasks". And "in theory this should be fixed if X is 
> fixed" does not cut it. X is pretty much _the_ most important thing to 
> optimize the interactive behavior of a Linux scheduler for. Also, 
> paradoxically, it is precisely the improvement of _X_ workloads that 
> RSDL argues with.
> 
> this regression has to be fixed before RSDL can be merged, simply 
> because it is a pretty negative effect that goes beyond any of the 
> visible positive improvements that RSDL brings over the current 
> scheduler. If it is better to fix X, then X has to be fixed _first_, at 
> least in form of a prototype patch that can be _tested_, and then the 
> result has to be validated against RSDL.
> 

RSDL is, above all else, fair. Predictably so.
Hacking around X's stupidity makes it no longer *be* RSDL.

Until they catch up to the early-90s technology-wise, we can just nice
-19 X.

-- 
Nicholas Miell <[EMAIL PROTECTED]>

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Reply via email to