If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

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.

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.

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).

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.

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.

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.

-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. :-/

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. ;-)

-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

-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.

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

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

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.