Originally posted by martinus
View Post
Announcement
Collapse
No announcement yet.
The ~200 Line Linux Kernel Patch That Does Wonders
Collapse
X
-
-
Originally posted by raj7095 View Postyeah, i tried everything. i put labour intensive tasks in idleprio, the ones that need interactivity in sched_iso, nice level doesnt make a huge difference for me, not that i noticed. but the thing is, even if i try all those, it still doesnt beat bfs 0.360 without any adjustments at all, it gets close, but it doesn't. i even put X in sched_iso and set rr_interval, sched_iso etc.
I am writing this reply on a 4 core machine without SMT, currently on 2.6.37-ck1 which includes bfs 0.363, compiling a kernel in the background (make -j 8), while playing a google tech talk video about quantum computing and doing the wobbly windows thingy. 8-)
All 4 cores are on 100%, load average is roughly 9. The user experience is as smooth as if the kernel compilation didn't happen in the background. Only the cpu fan is significantly louder than normal. 8-) So obviously I am not experiencing your regression...
Comment
-
Originally posted by martinus View Postif you ever find the reason for this let us know
I am writing this reply on a 4 core machine without SMT, currently on 2.6.37-ck1 which includes bfs 0.363, compiling a kernel in the background (make -j 8), while playing a google tech talk video about quantum computing and doing the wobbly windows thingy. 8-)
All 4 cores are on 100%, load average is roughly 9. The user experience is as smooth as if the kernel compilation didn't happen in the background. Only the cpu fan is significantly louder than normal. 8-) So obviously I am not experiencing your regression...
Comment
-
Originally posted by raj7095 View Postthe first patchset worked perfectly, the second patch fails at compile time for me. what does the second patch do anyways?
and AFTER THAT applied the 2nd patchset ?
or did you try to compile 2.6.37 *only with* the 2nd patchset ?
I've modified it that way that it should apply cleanly *on top* of 2.6.37 + 1st patchset
in a nutshell it should improve the autogroup (or group scheduling in general) even more:
[wake_afine fixes/improvements 0/3] Introduction
I've been looking at the wake_affine path to improve the group scheduling case
(wake affine performance for fair group sched has historically lagged) as well
as tweaking performance in general.
The current series of patches is attached, the first of which should probably be
considered for 2.6.38 since it fixes a bug/regression in the case of waking up
onto a previously (group) empty cpu. While the others can be considered more
forwards looking.
Originally posted by raj7095kerneloftruth, so far, your patches produce the fastest kernel 2.6.37 for me, but, it still not as fast as zen kernel version 2.6.36-zen3 with bfs. it gets pretty close though.
but if you take 2.6.37-zen* 's base and use these 2 patchsets (I've built my own similar kernel patchset like zen) it's the smoothest kernel EVER - so far
the best indicator for that is:
it almost never interrupts streaming / full throughput of my ethernet card during large i/o operations (meaning copying over large amounts of data between harddrives with device-mapper and encryption) - this also includes listening to webradio
Comment
-
Originally posted by raj7095 View Postyou can't apply the first patch onto the zen kernel, can you? btw, i patched in the wrong order, thats why it didnt work before. i corrected my mistake and the patches were successful.
but I highly doubt that they would apply cleanly
therefore you would need to fix those rejects (if that even worked afterwards)
Comment
Comment