Re: interactive task starvation

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wednesday 22 March 2006 00:24, Mike Galbraith wrote:
> On Tue, 2006-03-21 at 13:59 +0100, Willy Tarreau wrote:
> > That would suit me perfectly. I think I would set them both to zero.
> > It's not clear to me what workload they can help, it seems that they
> > try to allow a sometimes unfair scheduling.
>
> Correct.  Massively unfair scheduling is what interactivity requires.

To some degree, yes. Transient unfairness was all that it was supposed to do 
and clearly it failed at being transient. 

I would argue that good interactivity is possible with fairness by changing 
the design. I won't go there (to try and push it that is), though, as the 
opposition to changing the whole scheduler in place or making it pluggable 
has already been voiced numerous times over, and it would kill me to try and 
promote such an alternative ever again. Especially since the number of people 
willing to test interactive patches and report to lkml has dropped to 
virtually nil. 

The yardstick for changes is now the speed of 'ls' scrolling in the console. 
Where exactly are those extra cycles going I wonder? Do you think the 
scheduler somehow makes the cpu idle doing nothing in that timespace? Clearly 
that's not true, and userspace is making something spin unnecessarily, but 
we're gonna fix that by modifying the scheduler.... sigh

Cheers,
Con
-
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/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux