Announcement

Collapse
No announcement yet.

RIFS-ES Linux Kernel Scheduler Released

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

  • #76
    Originally posted by kernelOfTruth View Post
    could you please re-upload it ?

    it says uploaded 50 minutes ago but it's identical to the one downloaded approx. 19 hours ago and currently using

    *fingers crossed* that btrfs doesn't make that much trouble with the updated one


    I see - didn't know that there's that much to be managed


    sure, desktop performance/interactivity has been in a pretty bad state for me since 2.6.34 or even around 2.6.2* - so I'm glad I could help testing & pushing better alternatives forward


    thanks !
    Before the sleeper fairness feature is included, the desktop performance is snappy.
    With SD Scheduler the 2.6.21 kernel ran as snappy as BFS. However after 2.6.28, the desktop is not snappy anymore.

    Edit
    Now not only CFS is unfair, the people is being treated unfairly.
    The case we are having now is, the things that comes from the kernel developer are usually being correct(Ok..usually..). That is the unfairness.
    Last edited by 3766691; 07-04-2012, 12:54 PM.

    Comment


    • #77
      Originally posted by 3766691 View Post
      Before the sleeper fairness feature is included, the desktop performance is snappy.
      With SD Scheduler the 2.6.21 kernel ran as snappy as BFS. However after 2.6.28, the desktop is not snappy anymore.

      Edit
      Now not only CFS is unfair, the people is being treated unfairly.
      The case we are having now is, the things that comes from the kernel developer are usually being correct(Ok..usually..). That is the unfairness.
      yes, afaik I had a pretty nice patchset back then for 2.6.20 or 2.6.22 - with all necessary stuff included (grsecurity, etc.)

      the responsiveness under load was insane/awesome ^^

      good old times

      /sniff


      the recent cpu scheduler work on CFS might be good for big clusters and/or big boxen but for desktop there's simply too much overhead and unfairness involved

      also Linus & Ingo don't seem to care too much about desktop users

      or aren't that much affected yet to care enough

      Comment


      • #78
        Originally posted by kernelOfTruth View Post
        yes, afaik I had a pretty nice patchset back then for 2.6.20 or 2.6.22 - with all necessary stuff included (grsecurity, etc.)

        the responsiveness under load was insane/awesome ^^

        good old times

        /sniff


        the recent cpu scheduler work on CFS might be good for big clusters and/or big boxen but for desktop there's simply too much overhead and unfairness involved

        also Linus & Ingo don't seem to care too much about desktop users

        or aren't that much affected yet to care enough
        Anyway I have posted DMS-V1 fixed version just now. It doesn't use timeslice as a measurement of the quantum of a running task anymore.Benchmarks are attached to show that DMS can make super-low latency environment and it also shows that DMS is fair. DMS should not be used with ridicious load and it fits normal desktop load.

        Edit
        DMS can also fit the realtime environment for example airplane(These device needs low latency and they are used in critical environment)
        Last edited by 3766691; 07-05-2012, 09:58 AM.

        Comment


        • #79
          Originally posted by kernelOfTruth View Post
          yes, afaik I had a pretty nice patchset back then for 2.6.20 or 2.6.22 - with all necessary stuff included (grsecurity, etc.)

          the responsiveness under load was insane/awesome ^^

          good old times

          /sniff


          the recent cpu scheduler work on CFS might be good for big clusters and/or big boxen but for desktop there's simply too much overhead and unfairness involved

          also Linus & Ingo don't seem to care too much about desktop users

          or aren't that much affected yet to care enough
          Yes,they don't

          Comment


          • #80
            Originally posted by kernelOfTruth View Post
            yes, afaik I had a pretty nice patchset back then for 2.6.20 or 2.6.22 - with all necessary stuff included (grsecurity, etc.)

            the responsiveness under load was insane/awesome ^^

            good old times

            /sniff


            the recent cpu scheduler work on CFS might be good for big clusters and/or big boxen but for desktop there's simply too much overhead and unfairness involved

            also Linus & Ingo don't seem to care too much about desktop users

            or aren't that much affected yet to care enough
            Quite sorry for that. I don't have any old compiler.:-(

            Comment


            • #81
              Originally posted by kernelOfTruth View Post
              update:

              OMG - thank you so much Chen !

              you're da man


              kudos to you and Con



              in the past there have always been issues when using ZFS + 2 audio streams or other stuff (e.g. scrolling in the web and entering text)

              the result was that the computer effectively wasn't usable for anything else than running the backup job of ZFS and playing one audio track with hickups from time to time


              currently I'm running geek-sources 3.4.2 with ck-patchset ck2 for 3.4 kernel

              BFS 423 patched to 424 (is supposed to fix some i/o interactivity issues) and added your O(1) tweaks


              this is the best desktop kernel by far - since EVER


              having the data integrity features ZFS available and at the same time fully smooth desktop experience is full win-win in my books



              thanks again !


              now we only need to convince Con to include those (and/or additional upcoming) tweaks from you into BFS


              best of course would be to add BFS to mainline as an option to select for desktop users ...


              edit:

              ok, there's still the issue that HD videos (720p+) act slightly jerky but the sound in 99% is consistent

              so ZFSonLinux still needs some tweaking until it is fully suited for desktop/multimedia usage


              can't believe how much the CPU scheduler alone makes a difference in those things




              I'm using some additional CFQ tweaks - they also might help:



              source: http://unix.stackexchange.com/questi...system-caching
              BFS won't be adopted because Con is having argument with the mainline developer. Also, I have found a designing problem that BFS has, is the starvation of sleep task. They can't be scheduled as fair as the cpu-intensive task and as you said, will cause hickup. For example there are 6 task running and there nice value is 0. Five of them are while1 and the remain one is X. All of them should get 16.666% of cpu time. In fact X cannot get 16.666% of cpu time correctly.
              Chen
              Last edited by 3766691; 07-12-2012, 10:52 AM.

              Comment


              • #82
                I'm confused. Now we have RIFS, a patch for BFS and DMS?
                What to use? And where to download (at best for the 3.5 kernel)?

                Comment


                • #83
                  Originally posted by TAXI View Post
                  I'm confused. Now we have RIFS, a patch for BFS and DMS?
                  What to use? And where to download (at best for the 3.5 kernel)?
                  DMS has been dropped.

                  RIFS for 3.4 kernel: https://rifs-scheduler.googlecode.co...x2-kernel3.4.x
                  BFS(O(1) time complexity patch) for 3.4 kernel: https://rifs-scheduler.googlecode.com/files/bfs.c

                  Comment


                  • #84
                    I don't want to rush anything, but any chance we will see a patch for 3.5.x soon?

                    Comment


                    • #85
                      Originally posted by brenix View Post
                      I don't want to rush anything, but any chance we will see a patch for 3.5.x soon?
                      Sorry I have been late.

                      Here is the RIFS offical patch for 3.5.x kernel: http://rifs-scheduler.googlecode.com...fs-kernel3.5.x
                      No any changes have been made. The tweaks of the scheduler can be found at '/proc/sys/sched_rifs'.

                      Also I have rewritten several part of RIFS-ES scheduler. Many people reported that RIFS-ES scheduler can cause some strange behavior e.g. strange CPU load(Reported by ID:KernelOfTruth on Phoronix). The original RIFS-ES scheduler count the tick directly(p->tick_used++). Many people knows that tickless system(dynamic tick) tune the frequency of clock dynamicly. Sorry for making such kind of unacceptable mistake.
                      Here is the link for RIFS-ES patch for 3.5 kernel: http://rifs-scheduler.googlecode.com...es-kernel3.5.x

                      Chen

                      Comment


                      • #86
                        Originally posted by 3766691 View Post
                        Sorry I have been late.

                        Here is the RIFS offical patch for 3.5.x kernel: http://rifs-scheduler.googlecode.com...fs-kernel3.5.x
                        No any changes have been made. The tweaks of the scheduler can be found at '/proc/sys/sched_rifs'.

                        Also I have rewritten several part of RIFS-ES scheduler. Many people reported that RIFS-ES scheduler can cause some strange behavior e.g. strange CPU load(Reported by ID:KernelOfTruth on Phoronix). The original RIFS-ES scheduler count the tick directly(p->tick_used++). Many people knows that tickless system(dynamic tick) tune the frequency of clock dynamicly. Sorry for making such kind of unacceptable mistake.
                        Here is the link for RIFS-ES patch for 3.5 kernel: http://rifs-scheduler.googlecode.com...es-kernel3.5.x

                        Chen

                        no problem - life goes first

                        I was busy, too with other things and 3.4 + RIFS worked great so far

                        currently I'm running 3.5 kernel with rifs-kernel3.5.x and it booted up fine

                        great work - thanks !


                        there meanwhile where some improvements in ZFS, too - so with RIFS, some i/o scheduler it should be possible to have real multitasking during large data transfers running with ZFS

                        finally ! data consistency and safety + great performance


                        will test it during the next days and see how it goes ...

                        Comment


                        • #87
                          Originally posted by kernelOfTruth View Post
                          no problem - life goes first

                          I was busy, too with other things and 3.4 + RIFS worked great so far

                          currently I'm running 3.5 kernel with rifs-kernel3.5.x and it booted up fine

                          great work - thanks !


                          there meanwhile where some improvements in ZFS, too - so with RIFS, some i/o scheduler it should be possible to have real multitasking during large data transfers running with ZFS

                          finally ! data consistency and safety + great performance


                          will test it during the next days and see how it goes ...
                          Ok. Now I am running all my boxes with RIFS-ES(I mean this new version). Normally both of them perform well. RIFS-ES performs a bit better than RIFS on music playing.

                          Comment


                          • #88
                            with
                            CONFIG_NUMA=y
                            CONFIG_AMD_NUMA=y
                            CONFIG_X86_64_ACPI_NUMA=y
                            CONFIG_NODES_SPAN_OTHER_NODES=y
                            # CONFIG_NUMA_EMU is not set
                            CONFIG_NODES_SHIFT=9

                            i get
                            kernel/sched/rifs.c: In function ‘sd_init_ALLNODES’:
                            kernel/sched/rifs.c:5621:470: error: ‘SD_ALLNODES_INIT’ undeclared (first use in this function)
                            kernel/sched/rifs.c:5621:470: note: each undeclared identifier is reported only once for each function it appears in
                            kernel/sched/rifs.c: In function ‘sd_init_NODE’:
                            kernel/sched/rifs.c:5622:466: error: ‘SD_NODE_INIT’ undeclared (first use in this function)
                            make[3]: *** [kernel/sched/rifs.o] Fehler 1
                            make[2]: *** [kernel/sched] Fehler 2
                            make[1]: *** [kernel] Fehler 2

                            with "# CONFIG_NUMA is not set", the kernel compile without errors, please fix it

                            Debian SID 64bit
                            Vanilla Kernel 3.5 with rifs-es-kernel3.5.x or rifs-kernel3.5.x, no other patches

                            Comment


                            • #89
                              Originally posted by bug! View Post
                              with
                              CONFIG_NUMA=y
                              CONFIG_AMD_NUMA=y
                              CONFIG_X86_64_ACPI_NUMA=y
                              CONFIG_NODES_SPAN_OTHER_NODES=y
                              # CONFIG_NUMA_EMU is not set
                              CONFIG_NODES_SHIFT=9

                              i get
                              kernel/sched/rifs.c: In function ‘sd_init_ALLNODES’:
                              kernel/sched/rifs.c:5621:470: error: ‘SD_ALLNODES_INIT’ undeclared (first use in this function)
                              kernel/sched/rifs.c:5621:470: note: each undeclared identifier is reported only once for each function it appears in
                              kernel/sched/rifs.c: In function ‘sd_init_NODE’:
                              kernel/sched/rifs.c:5622:466: error: ‘SD_NODE_INIT’ undeclared (first use in this function)
                              make[3]: *** [kernel/sched/rifs.o] Fehler 1
                              make[2]: *** [kernel/sched] Fehler 2
                              make[1]: *** [kernel] Fehler 2

                              with "# CONFIG_NUMA is not set", the kernel compile without errors, please fix it

                              Debian SID 64bit
                              Vanilla Kernel 3.5 with rifs-es-kernel3.5.x or rifs-kernel3.5.x, no other patches
                              Ok. I will fix it tomorrow because I am really sleepy now.
                              The mainline kernel has already deprecated sd_init_ALLNODES and I had not notice this change.
                              Last edited by 3766691; 08-09-2012, 12:03 PM.

                              Comment


                              • #90
                                with
                                rifs-kernel3.5.x RIFS-SCHEDULER-3.5.x Offical 7 hours ago 7 hours ago 179 KB 6

                                kernel/exit.c: In function ‘__exit_signal’:
                                kernel/exit.c:148:32: error: ‘struct task_struct’ has no member named ‘se’
                                make[2]: *** [kernel/exit.o] Error 1
                                make[1]: *** [kernel] Error 2

                                Comment

                                Working...
                                X