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 rekiah View Post
    Con has abandoned the whole "automatic task grouping per TTY" idea. On October 6 he released his patch for BFS. 1 month later he said:

    [...]
    Proving how many un-niced jobs you can throw at your kernel compiles is not a measure of one's prowess. It is just a mindless test.
    I fully agree with Con on that one. Making an already complex scheduler more complex (and be it by 200 lines only) by introducing heuristics is the wrong way. The user space (read: the distro!) should make the choice. For instance, in my .profile and .bashrc it says:

    Code:
    if [ "$TERM" = "xterm" ]; then
      renice 19 $$ > /dev/null
    fi
    That is my personal choice to deal with all compilation work and other background tasks started from an xterm while preserving full interactivity using BFS. But whatever the mechanism, the distro plays the role of the OS (whereas the kernel is just, well, the kernel) and should deliver it out of the box.

    On a related note: something I dislike about the kernel developers' attitude is how the arguments are twisted. When it was about kicking out devfs, the mantra was "policy doesn't belong in the kernel". Now it is almost the opposite, because "user space is a mess". But I guess that is what you get from a model based on benevolent dictatorship (quote by Linus Torvalds).

    Comment


    • amazing

      this patch is unbelievably hot. On my laptop with a crappy intel gma 965 gfx card, I can now watch 1080p hd videos with full 60 frames with an extra stress of 80 % cpu usage. Before, I had to turn every process off to do that. Also, it really gave a noticeable increase in all my opengl apps. The bottom line is that this patch is amazing.

      Comment


      • Originally posted by korpenkraxar View Post
        I hear ya! It's a little weird though. It did not use to be like this in the first half or so of the decade. Did we all move to laptops with crappy IO and/or did the kernel change for the worse in terms of responsiveness?
        Our data consumables have increased.

        The videos we watch and even the web pages we browse to (thanks to Flash) are relatively more taxing to CPU and IO

        Comment


        • if you just want faster flash, then you can download google chrome and this addon for chrome: https://chrome.google.com/extensions...jgigdoeoanimeh
          basically, it forces youtube to play videos in html5, and not flash, which IMHO is a lot faster on linux that is. but, the quality is a little more pixelated, nothing noticable though.

          Comment


          • also, i noticed that bfs is a lot faster if you download pre-patched zen kernel from git repository and change zen-tune profile to desktop, enable sched_iso policy for x, and with timer frequency set to 1500 hz, yes you heard me right 1500 hz. now, that does miracles, at least on my laptop. on my desktop with i7, i can barely notice any improvements between the two; almost identical. but this patch works better under extremely heavy load. so to sum it up,
            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).

            Comment


            • 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