Announcement

Collapse
No announcement yet.

The v2 Rotary Interactivity Favor Scheduler

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

  • #16
    Originally posted by elmariachi View Post
    Where can we ask for support? I can't compile the kernel with this patch, must be doing something wrong (kind of new to the whole custom kernel scene)
    Oops.Could you send me your config.Also this patch is just availale for 3.3.x kernel right now

    Comment


    • #17
      It was me I had conflicting patches. Applied to vanilla 3.3.5 worked. It seems snappier, but that can also be placebo, I'll have to test some more. I also notice the lag when switching between apps, but I guess being snappy everywhere all the time is kind of utopic, no?

      Time to compile pacworld

      Comment


      • #18
        Originally posted by elmariachi View Post
        It was me I had conflicting patches. Applied to vanilla 3.3.5 worked. It seems snappier, but that can also be placebo, I'll have to test some more. I also notice the lag when switching between apps, but I guess being snappy everywhere all the time is kind of utopic, no?

        Time to compile pacworld

        Thanks for giving comment. The reason why it performs snappier is because it don't use complex and unaccurate algorithum to give priority to interactive task.
        I 'm going to try using the algorithum RIFS has used and EEVDF to priovide a more fairer scheduling. The switches between user-interactive task is smoother than BFS with high workload. It seems lag when switching to a cpu intensive task from interactive task. ;-)
        Last edited by 3766691; 05-16-2012, 10:00 AM.

        Comment


        • #19
          Are you the main author of RIFS?
          forgot to say: I'm using it with deadline, it seems to be faster than BFQ or CFQ. Noop and deadline are faster for me (normal hdd, non-sdd)

          funny thing: governor set to performance, no dyn ticks, nothing to save energy on, and I get almost exactly the same temperature as with BFS with everything on "eco" mode... maybe it's not the scheduler, but it's funny
          Last edited by elmariachi; 05-16-2012, 03:11 PM.

          Comment


          • #20
            Originally posted by elmariachi View Post
            Are you the main author of RIFS?
            forgot to say: I'm using it with deadline, it seems to be faster than BFQ or CFQ. Noop and deadline are faster for me (normal hdd, non-sdd)
            Yes,

            Originally posted by elmariachi View Post
            funny thing: governor set to performance, no dyn ticks, nothing to save energy on, and I get almost exactly the same temperature as with BFS with everything on "eco" mode... maybe it's not the scheduler, but it's funny
            There are not much relationship between a CPU scheduler and the temperature.
            Also, RIFS handles interactivity better than BFS with high workload. You can just try make -j128 and play your music or browse webpage with Firefox. According to my test result, 3.3.1 with BFS hanged my box with make -j512, and the music stopped for more than 1 minute, but with BFS it won't.

            Comment


            • #21
              Originally posted by 3766691 View Post
              Also, RIFS handles interactivity better than BFS with high workload. You can just try make -j128 and play your music or browse webpage with Firefox.
              It was made very clear by CK after his experiments with massive loads that BFS is not meant to be used with -j128. It is meant to be used with high workloads, but not with *ridiculous* workloads. High workload is something like -j10 on a quad core. 128 is ridiculous, and 512 is even beyond ridiculous.

              BFS is optimized for real use, not for throwing -j512 kernel builds at it. If you really intend to run such a massive workload (why?), you would run it SCHED_IDLEPRIO or nice 19 (or both). If you have written a new scheduler, posting information about how it handles -j128 "better" than the others says absolutely nothing about the merit of that scheduler. The only thing it says is that it handles something no one needs but doesn't say anything about how it handles stuff people actually *do* need.

              See:

              http://ck-hack.blogspot.com/2010/11/...y-comment.html
              Last edited by RealNC; 05-16-2012, 09:12 PM.

              Comment


              • #22
                Originally posted by RealNC View Post
                It was made very clear by CK after his experiments with massive loads that BFS is not meant to be used with -j128. It is meant to be used with high workloads, but not with *ridiculous* workloads. High workload is something like -j10 on a quad core. 128 is ridiculous, and 512 is even beyond ridiculous.

                BFS is optimized for real use, not for throwing -j512 kernel builds at it. If you really intend to run such a massive workload (why?), you would run it SCHED_IDLEPRIO or nice 19 (or both). If you have written a new scheduler, posting information about how it handles -j128 "better" than the others says absolutely nothing about the merit of that scheduler. The only thing it says is that it handles something no one needs but doesn't say anything about how it handles stuff people actually *do* need.

                See:

                http://ck-hack.blogspot.com/2010/11/...y-comment.html
                Maybe Im missing something but the test of a scheduler is how well it keeps certain tasks moving forward no matter what (obviously, the scheduler is only part of the problem, but all else being equal, I think what I wrote makes sense)
                The problem with using niceness is that linux tends not to pay too much attention to it (according to google).

                Comment


                • #23
                  Originally posted by RealNC View Post
                  It was made very clear by CK after his experiments with massive loads that BFS is not meant to be used with -j128. It is meant to be used with high workloads, but not with *ridiculous* workloads. High workload is something like -j10 on a quad core. 128 is ridiculous, and 512 is even beyond ridiculous.

                  BFS is optimized for real use, not for throwing -j512 kernel builds at it. If you really intend to run such a massive workload (why?), you would run it SCHED_IDLEPRIO or nice 19 (or both). If you have written a new scheduler, posting information about how it handles -j128 "better" than the others says absolutely nothing about the merit of that scheduler. The only thing it says is that it handles something no one needs but doesn't say anything about how it handles stuff people actually *do* need.

                  See:

                  http://ck-hack.blogspot.com/2010/11/...y-comment.html
                  Maybe you are focusing on the wrong things. The second main approach of RIFS is, whenever the amount of task running on the box is huge or not, the box is interactive enough.

                  Comment


                  • #24
                    Originally posted by liam View Post
                    Maybe Im missing something but the test of a scheduler is how well it keeps certain tasks moving forward no matter what (obviously, the scheduler is only part of the problem, but all else being equal, I think what I wrote makes sense)
                    The problem with using niceness is that linux tends not to pay too much attention to it (according to google).
                    BFS obeys niceness. It also obeys scheduler priorities. For example you can run -j512 on SCHED_IDLEPRIO without hickups. But my point is, you do *not* want to run -j512 to begin with.

                    If you are going to compare schedulers, you should do it using realistic loads, ranging from none and light to very heavy. You should not compare them using nonsensical loads.

                    Comment


                    • #25
                      Originally posted by 3766691 View Post
                      Maybe you are focusing on the wrong things. The second main approach of RIFS is, whenever the amount of task running on the box is huge or not, the box is interactive enough.
                      -j128 is not huge. -j10 is huge. Testing for -j128 will not allow you to draw any useful conclusions. A past patch in BFS (which was dropped) would allow you to run -j1024. If that patch was kept, then what? Would that mean BFS is the best scheduler to ever grace a kernel?

                      With that thinking, people would patch schedulers to run -j2048, and then higher. What then? There is simply no benefit in comparing schedulers on how "well" they run ridiculous loads. Even worse, some people will draw faulty conclusions.

                      Comment


                      • #26
                        Originally posted by RealNC View Post
                        -j128 is not huge. -j10 is huge. Testing for -j128 will not allow you to draw any useful conclusions. A past patch in BFS (which was dropped) would allow you to run -j1024. If that patch was kept, then what? Would that mean BFS is the best scheduler to ever grace a kernel?

                        With that thinking, people would patch schedulers to run -j2048, and then higher. What then? There is simply no benefit in comparing schedulers on how "well" they run ridiculous loads. Even worse, some people will draw faulty conclusions.
                        Actually you don't really know what -j stand for.
                        -j stand for the amount of cc1 tasks.
                        You are mixing all the sort of things together. :-/

                        Comment


                        • #27
                          Originally posted by RealNC View Post
                          BFS obeys niceness. It also obeys scheduler priorities. For example you can run -j512 on SCHED_IDLEPRIO without hickups. But my point is, you do *not* want to run -j512 to begin with.

                          If you are going to compare schedulers, you should do it using realistic loads, ranging from none and light to very heavy. You should not compare them using nonsensical loads.
                          Do you think people want to tune the policy of make every time ? Do you think people are patient enough to do a sort of things with shell every time ?
                          Eventually RIFS use it's simple algorithum to detect whether the task is a user-interactive task or a batch task.
                          I admit using shell more can make your typing speed faster. ;-)
                          Last edited by 3766691; 05-16-2012, 11:34 PM.

                          Comment


                          • #28
                            Originally posted by RealNC View Post
                            -j128 is not huge. -j10 is huge. Testing for -j128 will not allow you to draw any useful conclusions. A past patch in BFS (which was dropped) would allow you to run -j1024. If that patch was kept, then what? Would that mean BFS is the best scheduler to ever grace a kernel?

                            With that thinking, people would patch schedulers to run -j2048, and then higher. What then? There is simply no benefit in comparing schedulers on how "well" they run ridiculous loads. Even worse, some people will draw faulty conclusions.
                            BTW. You are focusing on the wrong things again and you are making conflict conclusion

                            Comment


                            • #29
                              Originally posted by RealNC View Post
                              -j128 is not huge. -j10 is huge. Testing for -j128 will not allow you to draw any useful conclusions. A past patch in BFS (which was dropped) would allow you to run -j1024. If that patch was kept, then what? Would that mean BFS is the best scheduler to ever grace a kernel?

                              With that thinking, people would patch schedulers to run -j2048, and then higher. What then? There is simply no benefit in comparing schedulers on how "well" they run ridiculous loads. Even worse, some people will draw faulty conclusions.
                              Both BFS and RIFS have a same basic approach.
                              Also I have mentioned that RIFS can keep being interactive enough from low workload to high workload.

                              Comment


                              • #30
                                Originally posted by 3766691 View Post
                                Do you think people want to tune the policy of make every time ? Do you think people are patient enough to do a sort of things with shell every time ?
                                Do you think people need to make -j128? Do you think that *if* they do that, for whatever reason (I can't think of even one, can you?), they shouldn't use nice -n19 or schedtool?

                                Originally posted by 3766691 View Post
                                Actually you don't really know what -j stand for.
                                -j stand for the amount of cc1 tasks.
                                You are mixing all the sort of things together. :-/
                                I know what -j does. And I know that -j512 serves no purpose in comparing schedulers.

                                Originally posted by 3766691 View Post
                                Both BFS and RIFS have a same basic approach.
                                Also I have mentioned that RIFS can keep being interactive enough from low workload to high workload.
                                You don't do that by pointing out that RIFS is "more interactive" with -j512. You do that with -j10 or such. The only reason to state that RIFS can manage -j512 and the other schedulers can't is to impress people who don't know how useless that benchmark is. So please don't do it.

                                Comment

                                Working...
                                X