Announcement

Collapse
No announcement yet.

The ~200 Line Linux Kernel Patch That Does Wonders

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Originally posted by martinus View Post
    ermm, is that on the same "nice" level and the same scheduling policy (SCHED_NORMAL)? In that case I am more surprised about your good results under 0.360. The whole idea of CF (="completely fair") and BF (="super simple") scheduling is the even distribution of the cpu resource without policy in the kernel.

    On my machine everything labour intensive is started at scheduling policy SCHED_IDLEPRIO (I used to change the "nice" level in the past which also affects "i/o nice") and all desktop activity, sound, films are totally smooth.

    I do wonder why people go through the hassle of complicated kernel patches when a straightforward scheduler and some user policy achieve so much better.
    yeah, 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.

    Comment


    • Originally posted by raj7095 View Post
      yeah, 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.
      if 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 martinus View Post
        if 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...
        u say u dont have smt, correct? i do, on a dual core, maybe that makes a difference in the new bfs. oh well, i will just stick to kerneloftruth's patches or the 2.6.36 version of zen kernel.

        Comment


        • Originally posted by raj7095 View Post
          u say u dont have smt, correct? i do, on a dual core, maybe that makes a difference in the new bfs. oh well, i will just stick to kerneloftruth's patches or the 2.6.36 version of zen kernel.
          any experience with my 2 patchsets yet ?

          Comment


          • Originally posted by kernelOfTruth View Post
            any experience with my 2 patchsets yet ?
            the first patchset worked perfectly, the second patch fails at compile time for me. what does the second patch do anyways?

            Comment


            • kerneloftruth, 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.

              Comment


              • Originally posted by raj7095 View Post
                the first patchset worked perfectly, the second patch fails at compile time for me. what does the second patch do anyways?
                you patched 2.6.37 with the 1st patchset

                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 raj7095
                kerneloftruth, 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.
                yeah, interactivity-wise BFS from 2.6.36-zen* still felt better

                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


                • you 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.

                  Comment


                  • Originally posted by raj7095 View Post
                    you 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.
                    you could try

                    but I highly doubt that they would apply cleanly

                    therefore you would need to fix those rejects (if that even worked afterwards)

                    Comment


                    • ok, a few hunks fail, but i can fix that.

                      Comment

                      Working...
                      X