Re: [ANNOUNCE] RSDL completely fair starvation free interactive cpu scheduler

[Gene Heskett <gene.heskett@gmail.com>]

On Monday 05 March 2007, Lee Revell wrote:
>On 3/5/07, Gene Heskett <gene.heskett@gmail.com> wrote:
>> On Monday 05 March 2007, Nicolas Mailhot wrote:
>> >This looks like -mm stuff if you want it in 2.6.22
>>
>> This needs to get to 2.6.21, it really is that big an improvement.
>
>You can probably speed things up by regression testing against a wide
>range of non-desktop workloads and posting your numbers...
>
>Lee

I'm not THAT much of a tester other than seeing how it does my personal 
workload, such as working over an image in Gimp, and then printing it, 
while I'm reading and reply to email, browsing the web or playing 
solitaire.  At all of this is marches along rather nicely, and generally 
unaffected by the fetchmail/procmail/spamc loop every 90 seconds in the 
background.  glxgears runs about 1190 fps here, and loses maybe 4 or 5 
frames when the system beeps at me to indicate a new mail has arrived.  
Strangely, the wah wah wah wah it plays for a spam sent to trash doesn't 
bother glxgears any more then the 1/3 second beep.

I might add that its a bit puzzling to me, that when these pregnant pauses 
occur without the patch, gkrellm cpu usage, at an update frequency of 1 
second granularity, doesn't show ANY change, or so little it can't 
possibly explain why I'm sitting here for 10 seconds or more, waiting for 
what I've typed to actually show up on screen.  I should see a spike in 
one of the three cpu usage windows, but the whole thing is sitting at 2% 
total cpu while my application is starved and frozen for 10+ seconds at a 
time. 

That in itself tells this unwashed user that the scheduler is spinning its 
wheel somewhere as it exists today without this patch.  With this patch, 
those pauses are very small fractions of a second.  Just barely 
detectable.  And, system or user activity now properly registers in the 
gkrellm display, going up to about 15% user if I stand on the left arrow 
to backspace the cursor here in kmails composer screen.

To me, this plays great in Peoria, put it in ASAP and the users will bow 
at your feet to pay homage to Con for submitting it.

I am having a hard time figuring out why Con has thrown patches that might 
have helped over the fence only to have them go splat in the night.  When 
Con gets frustrated enough to post about it, everybody seems to turn a 
deaf ear, like he's committed some cardinal sin and I don't understand 
why or what.

This list is about development, supposedly in an orderly fashion, but 
occasionally a patch comes along that's so obviously correct it deserves 
to be fast tracked, and this is one of those.  To me this is as important 
as the filesystem corruption that was chased all the way thru from around 
2.6.17 to the middle of the 20-rc stuff.  Nobody wasted any time getting 
that into the next rc when it was finally found.  Fortunately I didn't 
get bit, possibly due to my habit of restarting azureas to seed, and I've 
seen it re-suck a few pieces to correct itself more than once.

Andrew, please, get this one in ASAP, but promise me an -mm won't trash 
half my filesystems like one I tried 2-3 years ago did.  Its a shame when 
Con submits a patch, and only 2 people post their experiences from using 
it.

-- 
Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)