|| ||Gene Heskett <gene.heskett-AT-gmail.com>|
Andrew Morton <akpm-AT-linux-foundation.org>,
Linus Torvalds <torvalds-AT-linux-foundation.org>|
|| ||Re: [ANNOUNCE] RSDL completely fair starvation free interactive cpu
|| ||Mon, 05 Mar 2007 14:19:25 -0500|
|| ||"Lee Revell" <rlrevell-AT-joe-job.com>,
"Nicolas Mailhot" <nicolas.mailhot-AT-laposte.net>|
On Monday 05 March 2007, Lee Revell wrote:
>On 3/5/07, Gene Heskett <email@example.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...
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
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
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
to post comments)