On Monday 05 March 2007, Lee Revell wrote: >On 3/5/07, Gene Heskett <[EMAIL PROTECTED]> 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) - 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/
