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 raj7095 View Post
    ...and with timer frequency set to 1500 hz, yes you heard me right 1500 hz.
    Blasphemy!!!

    How about battery life? I read somewhere that setting a high value for the timer frequency would result in more wake-ups per second, which in turn would reduce battery life since the cpu spends less time in the off (sleep, wait, whatever... I don't know) state.

    Comment


    • Originally posted by devius View Post
      Blasphemy!!!

      How about battery life? I read somewhere that setting a high value for the timer frequency would result in more wake-ups per second, which in turn would reduce battery life since the cpu spends less time in the off (sleep, wait, whatever... I don't know) state.
      well, obviously the battery life will be reduced. so, thats why i have a backup kernel at bootup which uses only 100 hz timer with dynamic ticks and without bfs. but, mostly i use my laptop with power supply available. That is another good thing about this patch, it doesn't increase battery usage as compared to bfs.

      Comment


      • Originally posted by raj7095 View Post
        [...]

        bfs: amazing multitasking from low-medium cpu usage + overall performance boost (at least graphics are faster). although any more than 16 cores makes this scheduler useless.
        this patch: not noticable unless you got an extremely cpu-intensive task such as compiling or running 50 firefox tabs with all of them running 1080p videos (ok not really but you get the idea).
        I totally agree that bfs gives a new lease of life to uniprocessor and low-end computers, in which case the auto-iso patch helps some more to provide excellent interactivity. And although I fully understand the request for hard numbers, you need to experience it to believe it.

        Admittedly, with modern high-end systems the difference between bfs and standard is less noticable. But I claim, even extremely cpu intensive tasks are handled better by bfs (in terms of preserving interactivity for the other tasks) IF you make use of "nice" or "schedtool". And as I said earlier, the end user need not know about "nice" or "schedtool". The distro should.

        Comment


        • Originally posted by martinus View Post
          I totally agree that bfs gives a new lease of life to uniprocessor and low-end computers, in which case the auto-iso patch helps some more to provide excellent interactivity. And although I fully understand the request for hard numbers, you need to experience it to believe it.

          Admittedly, with modern high-end systems the difference between bfs and standard is less noticable. But I claim, even extremely cpu intensive tasks are handled better by bfs (in terms of preserving interactivity for the other tasks) IF you make use of "nice" or "schedtool". And as I said earlier, the end user need not know about "nice" or "schedtool". The distro should.
          no need for BFS

          CFS with autogroup enabled also works very well (I'm currently using a highly-patched kernel with it based on 2.6.37 using CFS-parts from 2.6.38) - if you also add the mmu-preemptible patchset, ck-patchset, kswapd fixes some scheduler fixes and io-less dirty throttling you won't recognize your system under load

          it's like a completely new box

          zen-stable has all/most of it included so give it a try - now:

          http://git.zen-kernel.org/zen-stable/


          or you wait until 2.6.38 is at least at rc6 and test that

          Comment


          • hey, anyone notice how much worse bfs' multitasking is in zen kernel 2.6.37 compared to 2.6.36?

            Comment


            • Originally posted by raj7095 View Post
              hey, anyone notice how much worse bfs' multitasking is in zen kernel 2.6.37 compared to 2.6.36?
              yeah,

              weird - isn't it ?

              therefore I'm using 2.6.37 with CFS from 2.6.38

              no idea what changed in vanilla/mainline so that performance has to suffer that much with BFS

              BFS was always better than CFS - hopefully Con will push out some improvements over time

              Comment


              • how do you use cfs from 2.6.38 in 2.6.37?

                Comment


                • also, how much performance gain does the cfs from kernel 2.6.38 give you compared to the cfs in kernel 2.6.37?

                  Comment


                  • You trade some throughput for more resposniveness, there are ways around this however, its just more complicated to code for.

                    This patch is really a hack in alot of ways. But it might work great for desktop users. It'll suck for servers. Lots of reqource contention. It'll suck for scientific uses etc where you need to jam through maximum data as fast as you can.

                    Its really very application specific. I tried this patch on a build. I wasn't very impressed.

                    Comment


                    • i dont really care about the throughput on my machine though, of course there is a minimum requirement but still. is the newer cfs faster in any way? if it is, can someone guide me to some instructions or a pre-patched kernel?

                      Comment

                      Working...
                      X