The v2 Rotary Interactivity Favor Scheduler

[3766691]

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?

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

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

[RealNC]

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.

[Diana]

I really don't know, why you released _that_ patch into the wild so early.

There's much unneeded stuff in it (approx 60% of raw text size).
Didn't you promise to clean it up?

And there are many other unclear things:
* It IS based on the most recent CK1-patches
--> including what? excluding what? and why?

* Why can't I switch VTs anymore? Once switched away from X I can't get back or to the root console VT.
--> That's a NOGO!!! Reboot needed.

I like BFS (plus BFQ) for years now. Have experimented much with patches to include from CK.

And I also don't like approaches sounding like "my cc1 in the 1000. thread works well with Firefox' scrolling." <-- When even the basics do not work!

Best regards,
Diana

Kernel 3.3.6 + BFS(pure) + mm-drop_swap_cache_aggressively.patch + BFQ

[3766691]

I really don't know, why you released _that_ patch into the wild so early.

There's much unneeded stuff in it (approx 60% of raw text size).
Didn't you promise to clean it up?

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

And I also don't like approaches sounding like "my cc1 in the 1000. thread works well with Firefox' scrolling."

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.

When even the basics do not work!

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

* It IS based on the most recent CK1-patches

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)

[elmariachi]

So you say you can make it as fast (throughoutput) as BFS?
Yeah, it needs to be cleaned.. seems good thoughl.

[Diana]

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!

Keep up your enthusiasm and good work,

Diana

[crazycheese]

I think this scheduler need PTS benchmark in both throughput and interactivity compared to noop/deadline/cfs/bfs. This would solve all theoretical-or-not issues.
Great work, keep it up!

[3766691]

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

It seems like that the task have been dropped out from runqueue.I have fixed a bug that is related to the idle task dropping problem but i haven't post it yet.

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.

If you did at least document it -- I could patch these ones out at least on my own.

I m now writing it with my phone ;-)

[3766691]

So you say you can make it as fast (throughoutput) as BFS?
Yeah, it needs to be cleaned.. seems good thoughl.

Yes. Trying...
However i won't care too much about it because Linux users now want a responsive OS. They don't care too much about CPU intensive task.

[RealNC]

I think this scheduler need PTS benchmark in both throughput and interactivity compared to noop/deadline/cfs/bfs.

What? What's "noop" and "deadline"?