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.

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.

OK. Have you read my benchmark ?

Don't you understand what i am talking about? "RIFS can handle interactive well from low workload to high workload on desktop." I have mentioned about that and seems you haven't read my newest post. That means you don't have anything to debate with me, all right ?

OK I mention one more things. U haven't try and you are just claiming that *RIFS* is really bad, so anyway you don't have anything to debate with me

Comment

Do you think a normal person like to renice or use schedtool every time for a lower latency or anything else?

No. And it's not needed. Unless by "every time" you mean building with -j128, which stretches the definition of "every time" quite a lot. No one does that every time when building something. On a quad, you do -j4 with BFS and -j5 with CFS. You do not do a make -j128 "every time".

OK. Have you read my benchmark ?

Have you clarified that benching for make -j128 means nothing?

Don't you understand what i am talking about? "RIFS can handle interactive well from low workload to high workload on desktop." I have mentioned about that and seems you haven't read my newest post. That means you don't have anything to debate with me, all right ?

That's fine, but drawing conclusions because a scheduler handles make jobs of 128 and higher better than another is wrong.

OK I mention one more things. U haven't try and you are just claiming that *RIFS* is really bad, so anyway you don't have anything to debate with me

There is no such claim. I'm simply pointing out that readers should ignore test results with absurd work loads. They server no comparative purpose.

It is UNNECESSARY to care about the code frame. The most important things of a cpu scheduler is the algorithum.
Also I would like to talk about the code frame of BFS and Modular Scheduler(mainline)
BFS->SD/RSDL->O(1)
Modular Scheduler(mainline)->SD/RSDL->O(1)

Comment

All right. I have promised that but I seldom turn on my computer in weekday.

This solves some of the interactivity problem of BFS(BFS is interactive, but still there is). The throughput is a bit lower than BFS.I am going to test with RIFS v3 on Sat.

Have you tried. Seems that you didn't try.

It is UNNECESSARY to care about the code frame. The most important things of a cpu scheduler is the algorithum.
Also I would like to talk about the code frame of BFS and Modular Scheduler(mainline)
BFS->SD/RSDL->O(1)
Modular Scheduler(mainline)->SD/RSDL->O(1)

Of course I tried your patch. Otherwise I would not have encountered the BUG I mentioned that you didn't post a comment on: Switching VTs from X to console works but not back. And this was the only sense I meant when saying "The basics don't work." Please, don't read me wrong: I don't say your scheduler isn't good or is even worse.

I do care about the code frame: I'm not able to compare the pure BFS algorithm with your one when you add/keep extra parts of the CK1 patchset and don't document it. If you did at least document it -- I could patch these ones out at least on my own.

Maybe you can take this into account when working on RIFS v3, I'm looking forward to. Can you notify in this place, when it's ready, please!

I do care about the code frame: I'm not able to compare the pure BFS algorithm with you one when you add/keep extra parts ofthe CK1 patchset and don't document

RIFS and BFS are two different things. The former one use multiple feedback queue algoritjm and the latter one use EEVDF algorithm.RIFS will increase the prio of the task which have just run half of a time slice and sleep.If a task has run out of time slice， the prio will drop.If an interactive task
has run out of time slice the prio of it will drop and prio will equal to nice.