Re: [PATCH] Staircase scheduler v7.4

[Ed Sweetman <safemode@comcast.net>]

Nick Piggin wrote:

> Peter Williams wrote:
>
>> Nick Piggin wrote:
>>
>>> Felipe Alfaro Solana wrote:
>>>
>>>> I have tested 2.6.7-bk10 plus from_2.6.7_to_staircase_7.7 patch and,
>>>> while it's definitively better than previous versions, it still 
>>>> feels a
>>>> little jerky when moving windows in X11 wrt to -mm3. Renicing makes 
>>>> it a
>>>> little bit smoother, but not as much as -mm3 without renicing.
>>>>
>>>
>>> You know, if renicing X makes it smoother, then that is a good thing
>>> IMO. X needs large amounts of CPU and low latency in order to get
>>> good interactivity, which is something the scheduler shouldn't give
>>> to a process unless it is told to.
>>
>>
>>
>> I agree.  Although the X servers CPU usage is usually relatively low 
>> (less than 5%) it does have periods when it can get quite high 
>> (greater than 80%) for reasonably long periods.  This makes it 
>> difficult to come up with a set of rules for CPU allocation that 
>> makes sure the X server gets what it needs (when it needs it) without 
>> running the risk of giving other tasks with similar load patterns 
>> unnecessary and unintentional preferential treatment.
>>
>
> Well exactly. This is what the standard scheduler tries to do, and
> it does have weird starvation and priority problems that pop up.
>
>> However, I think that there is still a need for automatic boosts for 
>> some tasks.  For instance, programs such as xmms and other media 
>> streamers are ones whose performance could worsen as a result of the 
>> X server being reniced unless it is treated specially and the boost 
>> they are given needs to be enough to put them before the X server in 
>> priority order.  But renicing X would enable a tightening of the 
>> rules that govern the automatic dispensing of preferential treatment 
>> to tasks that are perceived to be interactive which should be good 
>> for overall system performance.
>
>
> I agree renicing X is helpful.

I've seen different audio players react very differently in the same 
situations with the same kernel.  Are people testing alternatives to 
make sure it's not just the program being bad?  Maybe the people doing 
these scheduler tests are using all the popular media players and 
different widely available gui systems to make sure they're not tuning 
the kernel for a specific program.   That should probably be clarified. 

I think it ought to be made clear that the gain is being made for a type 
of program, and not a single one, a type of workload and not a workload 
consisting of this and that and this program.  That can include 
different windowing systems (xfree86 vs non-free X implimentations or 
DirectFB) and gtk vs qt vs no toolkit..  This way obvious userspace bugs 
can be exposed and all this tuning wont be done for helping keep bugs 
and bad implimentations in use.