Announcement

Collapse
No announcement yet.

The v2 Rotary Interactivity Favor Scheduler

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

  • #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:

    I've had every man and his dog either drop into IRC or email me asking me what my thoughts are on the grouping tasks by tty layer patch disc...
    Last edited by RealNC; 16 May 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; 16 May 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