RSDL cpu scheduler for 2.6.21-rc3-mm2

What follows this email is a patch series for the latest version of the RSDL cpu scheduler (ie v0.29). I have addressed all bugs that I am able to reproduce in this version so if some people would be kind enough to test if there are any hidden bugs or oops lurking, it would be nice to know in anticipation of putting this back in -mm. Thanks.

Full patch for 2.6.21-rc3-mm2:
http://ck.kolivas.org/patches/staircase-deadline/2.6.21-rc3-mm2-rsdl-0.29.patch

Hi Con,

Quoted 9 lines · Con Kolivas

What follows this email is a patch series for the latest version of the RSDL cpu scheduler (ie v0.29). I have addressed all bugs that I am able to reproduce in this version so if some people would be kind enough to test if there are any hidden bugs or oops lurking, it would be nice to know in anticipation of putting this back in -mm. Thanks.

Full patch for 2.6.21-rc3-mm2:
http://ck.kolivas.org/patches/staircase-deadline/2.6.21-rc3-mm2-rsdl-0.29
.patch

I'm seeing a cpu distribution problem running this on my P4 box.

Scenario:
listening to music collection (mp3) via Amarok. Enable Amarok visualization gforce, and size such that X and gforce each use ~50% cpu. Start rip/encode of new CD with grip/lame encoder. Lame is set to use both cpus, at nice 5. Once the encoders start, they receive considerable more cpu than nice 0 X/Gforce, taking ~120% and leaving the remaining 80% for X/Gforce and Amarok (when it updates it's ~12k entry database) to squabble over.

With 2.6.21-rc3, X/Gforce maintain their ~50% cpu (remain smooth), and the encoders (100%cpu bound) get whats left when Amarok isn't eating it.

I plunked the above patch into plain 2.6.21-rc3 and retested to eliminate other mm tree differences, and it's repeatable. The nice 5 cpu hogs always receive considerably more that the nice 0 sleepers.

Thanks for the report. I'm assuming you're describing a single hyperthread P4 here in SMP mode so 2 logical cores. Can you elaborate on whether there is any difference as to which cpu things are bound to as well? Can you also see what happens with lame not niced to +5 (ie at 0) and with lame at nice +19.

Quoted 2 lines

Full patch for 2.6.21-rc3-mm2:
http://ck.kolivas.org/patches/staircase-deadline/2.6.21-rc3-mm2-rsdl-0.29.patch

I'm seeing a cpu distribution problem running this on my P4 box.

With 2.6.21-rc3, X/Gforce maintain their ~50% cpu (remain smooth), and the encoders (100%cpu bound) get whats left when Amarok isn't eating it.

I plunked the above patch into plain 2.6.21-rc3 and retested to eliminate other mm tree differences, and it's repeatable. The nice 5 cpu hogs always receive considerably more that the nice 0 sleepers.

Quoted 9 lines · Mike Galbraith

Quoted 2 lines

Full patch for 2.6.21-rc3-mm2:
http://ck.kolivas.org/patches/staircase-deadline/2.6.21-rc3-mm2-rsdl-0.29.patch

I'm seeing a cpu distribution problem running this on my P4 box.

With 2.6.21-rc3, X/Gforce maintain their ~50% cpu (remain smooth), and the encoders (100%cpu bound) get whats left when Amarok isn't eating it.

Quoted 3 lines

I plunked the above patch into plain 2.6.21-rc3 and retested to eliminate other mm tree differences, and it's repeatable. The nice 5 cpu hogs always receive considerably more that the nice 0 sleepers.

hm. Do you get the same same problem on UP too? (i.e. lets eliminate any SMP/HT artifacts)

I'll boot up nosmp and report back

Quoted 9 lines · Mike Galbraith

Quoted 2 lines

Full patch for 2.6.21-rc3-mm2:
http://ck.kolivas.org/patches/staircase-deadline/2.6.21-rc3-mm2-rsdl-0.29.patch

I'm seeing a cpu distribution problem running this on my P4 box.

With 2.6.21-rc3, X/Gforce maintain their ~50% cpu (remain smooth), and the encoders (100%cpu bound) get whats left when Amarok isn't eating it.

Quoted 3 lines

I plunked the above patch into plain 2.6.21-rc3 and retested to eliminate other mm tree differences, and it's repeatable. The nice 5 cpu hogs always receive considerably more that the nice 0 sleepers.

hm. Do you get the same same problem on UP too? (i.e. lets eliminate any SMP/HT artifacts)

Quoted 11 lines · Ingo Molnar

Quoted 10 lines · Mike Galbraith

Quoted 3 lines

Full patch for 2.6.21-rc3-mm2:
http://ck.kolivas.org/patches/staircase-deadline/2.6.21-rc3-mm2-rsdl-
0.29.patch

I'm seeing a cpu distribution problem running this on my P4 box.

With 2.6.21-rc3, X/Gforce maintain their ~50% cpu (remain smooth), and the encoders (100%cpu bound) get whats left when Amarok isn't eating it.

Quoted 6 lines

Quoted 3 lines

I plunked the above patch into plain 2.6.21-rc3 and retested to eliminate other mm tree differences, and it's repeatable. The nice 5 cpu hogs always receive considerably more that the nice 0 sleepers.

hm. Do you get the same same problem on UP too? (i.e. lets eliminate any SMP/HT artifacts)

Behavior is slightly different with a UP kernel. Neither encoder receives more cpu than X, but they each still receive more than gforce. The distribution of X/Gforce vs lame/lame averages per eyeball to roughly ~50:50.

I noticed Con posted an accounting fix, and applied it. No change.

Quoted 19 lines · Mike Galbraith

Quoted 11 lines · Ingo Molnar

Quoted 10 lines · Mike Galbraith

Quoted 3 lines

Full patch for 2.6.21-rc3-mm2:
http://ck.kolivas.org/patches/staircase-deadline/2.6.21-rc3-mm2-rsd
l- 0.29.patch

I'm seeing a cpu distribution problem running this on my P4 box.

With 2.6.21-rc3, X/Gforce maintain their ~50% cpu (remain smooth), and the encoders (100%cpu bound) get whats left when Amarok isn't eating it.

Quoted 6 lines

Quoted 3 lines

I plunked the above patch into plain 2.6.21-rc3 and retested to eliminate other mm tree differences, and it's repeatable. The nice 5 cpu hogs always receive considerably more that the nice 0 sleepers.

hm. Do you get the same same problem on UP too? (i.e. lets eliminate any SMP/HT artifacts)

Quoted 6 lines

Behavior is slightly different with a UP kernel. Neither encoder receives more cpu than X, but they each still receive more than gforce. The distribution of X/Gforce vs lame/lame averages per eyeball to roughly ~50:50.

I noticed Con posted an accounting fix, and applied it. No change.

So the lames are nice 5 which means they should receive 75% of the cpu that nice 0 tasks receive so they should get 43% of the cpu...

Just a couple of questions;

The X/Gforce case; do they alternate cpu between them? By that I mean when they're the only thing running does the cpu load summate to 1 or does it summate to 2?

I'll save you the trouble. I just checked myself and indeed the load is only
1. What this means is that although there are 2 tasks running, only one is running at any time making a total load of 1. So, if we add two other tasks that add 2 more to the load the total load is 3. However if we weight the other two tasks at nice 5, they only add .75 each to the load making a weighted total of 2.5. This means that X+Gforce together should get a total of 1/2.5 or 40% of the overall cpu. That sounds like exactly what you're describing is happening.

Quoted 8 lines · Con Kolivas

I'll save you the trouble. I just checked myself and indeed the load is only 1. What this means is that although there are 2 tasks running, only one is running at any time making a total load of 1. So, if we add two other tasks that add 2 more to the load the total load is 3. However if we weight the other two tasks at nice 5, they only add .75 each to the load making a weighted total of 2.5. This means that X+Gforce together should get a total of 1/2.5 or 40% of the overall cpu. That sounds like exactly what you're describing is happening.

Hmm. So... anything that's client/server is going to suffer horribly unless niced tasks are niced all the way down to 19?

Quoted 10 lines · Mike Galbraith

Quoted 8 lines · Con Kolivas

I'll save you the trouble. I just checked myself and indeed the load is only 1. What this means is that although there are 2 tasks running, only one is running at any time making a total load of 1. So, if we add two other tasks that add 2 more to the load the total load is 3. However if we weight the other two tasks at nice 5, they only add .75 each to the load making a weighted total of 2.5. This means that X+Gforce together should get a total of 1/2.5 or 40% of the overall cpu. That sounds like exactly what you're describing is happening.

Quoted 2 lines

Hmm. So... anything that's client/server is going to suffer horribly unless niced tasks are niced all the way down to 19?

Fortunately most client server models dont usually have mutually exclusive cpu use like this X case. There are many things about X that are still a little (/me tries to think of a relatively neutral term)... wanting. :(

Quoted 15 lines · Con Kolivas

Quoted 13 lines · Mike Galbraith

Quoted 9 lines · Con Kolivas

I'll save you the trouble. I just checked myself and indeed the load is only 1. What this means is that although there are 2 tasks running, only one is running at any time making a total load of 1. So, if we add two other tasks that add 2 more to the load the total load is 3. However if we weight the other two tasks at nice 5, they only add .75 each to the load making a weighted total of 2.5. This means that X+Gforce together should get a total of 1/2.5 or 40% of the overall cpu. That sounds like exactly what you're describing is happening.

Hmm. So... anything that's client/server is going to suffer horribly unless niced tasks are niced all the way down to 19?

Quoted 4 lines

Fortunately most client server models dont usually have mutually exclusive cpu use like this X case. There are many things about X that are still a little (/me tries to think of a relatively neutral term)... wanting. :(

But the reality of X is what we have to deal with.

This scheduler seems to close the corner cases of the interactivity estimator, but this "any background load is palpable" thing is decidedly detrimental to interactive feel.

When I looked into keeping interactive tasks responsive, I came to the conclusion that I just couldn't get there from here across the full spectrum of cpu usage without a scheduler hint. Interactive feel is absolutely dependent upon unfairness in many cases, and targeting that unfairness gets it right where heuristics sometimes can't.

-Mike

Quoted 1 line · Mike Galbraith

Now I think you're getting carried away because of your expectations from the previous scheduler and its woefully unfair treatment towards interactive tasks. Look at how you're loading up your poor P4 even with HT. You throw 2 cpu hogs only gently niced at it on top of your interactive tasks. If you're happy to nice them +5, why not more? And you know as well as anyone that the 2nd logical core only gives you ~25% more cpu power overall so you're asking too much of it. Let's not even talk about how lovely this will (not) be once SMT nice gets killed off come 2.6.21 and nice does less if "buyer beware" you chose to enable HT in your own words.

Quoted 5 lines

When I looked into keeping interactive tasks responsive, I came to the conclusion that I just couldn't get there from here across the full spectrum of cpu usage without a scheduler hint. Interactive feel is absolutely dependent upon unfairness in many cases, and targeting that unfairness gets it right where heuristics sometimes can't.

See above. Your expectations of what you should be able to do are simply skewed. Find what cpu balance you loved in the old one (and I believe it wasn't that much more cpu in favour of X if I recall correctly) and simply change the nice setting on your lame encoder - since you're already setting one anyway.

We simply cannot continue arguing that we should dish out unfairness in any manner any more. It will always come back and bite us where we don't want it.

We are getting good interactive response with a fair scheduler yet you seem intent on overloading it to find fault with it.

The test scenario was one any desktop user might do with every expectation responsiveness of the interactive application remain intact. I understand the concepts here Con, and I'm not knocking your scheduler. I find it to be a step forward on the one hand, but a step backward on the other.

Quoted 2 lines

We are getting good interactive response with a fair scheduler yet you seem intent on overloading it to find fault with it.

I'm not trying to find fault, I'm TESTING AND REPORTING. Was.

Quoted 5 lines · Mike Galbraith

The test scenario was one any desktop user might do with every expectation responsiveness of the interactive application remain intact. I understand the concepts here Con, and I'm not knocking your scheduler. I find it to be a step forward on the one hand, but a step backward on the other.

ok, then that step backward needs to be fixed.

Quoted 4 lines

Quoted 2 lines

We are getting good interactive response with a fair scheduler yet you seem intent on overloading it to find fault with it.

I'm not trying to find fault, I'm TESTING AND REPORTING. Was.

Con, could you please take Mike's report of this regression seriously and address it? Thanks,

Quoted 7 lines

Quoted 4 lines

Quoted 2 lines

We are getting good interactive response with a fair scheduler yet you seem intent on overloading it to find fault with it.

I'm not trying to find fault, I'm TESTING AND REPORTING. Was.

Con, could you please take Mike's report of this regression seriously and address it? Thanks,

Sure.

Mike the cpu is being proportioned out perfectly according to fairness as I mentioned in the prior email, yet X is getting the lower latency scheduling. I'm not sure within the bounds of fairness what more would you have happen to your liking with this test case?

Quoted 8 lines · Con Kolivas

Quoted 7 lines

Quoted 4 lines

Quoted 2 lines

We are getting good interactive response with a fair scheduler yet you seem intent on overloading it to find fault with it.

I'm not trying to find fault, I'm TESTING AND REPORTING. Was.

Con, could you please take Mike's report of this regression seriously and address it? Thanks,

Quoted 6 lines

Sure.

Mike the cpu is being proportioned out perfectly according to fairness as I mentioned in the prior email, yet X is getting the lower latency scheduling. I'm not sure within the bounds of fairness what more would you have happen to your liking with this test case?

Con,

I think what we're discovering is that a "fair scheduler" is
not going to cut it. After all, running X and ripping CD's and MP3 encoding them is not exactly an esoteric use case. And like it or not, "nice" defaults to 4.

I suspect Mike is right; the only way to deal with this
regression is some scheduler hints from the desktop subsystem (i.e., X and friends). Yes, X is broken, it's horrible, yadda, yadda, yadda. It's also what everyone is using, and it's a fact of life. Just like we occasionally have had to work around ISA braindamage, and x86 architecture braindamage, and ACPI braindamage all inflicted on us by Intel. This is just life, and sometimes the clean, elegant solution is not enough.

Mike the cpu is being proportioned out perfectly according to fairness as I mentioned in the prior email, yet X is getting the lower latency scheduling. I'm not sure within the bounds of fairness what more would you have happen to your liking with this test case?

Quoted 4 lines · Con Kolivas

Mike the cpu is being proportioned out perfectly according to fairness as I mentioned in the prior email, yet X is getting the lower latency scheduling. I'm not sure within the bounds of fairness what more would you have happen to your liking with this test case?

It has been said that "perfection is the enemy of good". The two interactive tasks receiving 40% cpu while two niced background jobs receive 60% may well be perfect, but it's damn sure not good.

Quoted 9 lines · Mike Galbraith

Quoted 4 lines · Con Kolivas

Mike the cpu is being proportioned out perfectly according to fairness as I mentioned in the prior email, yet X is getting the lower latency scheduling. I'm not sure within the bounds of fairness what more would you have happen to your liking with this test case?

It has been said that "perfection is the enemy of good". The two interactive tasks receiving 40% cpu while two niced background jobs receive 60% may well be perfect, but it's damn sure not good.

Well, the real problem is really "server that works on behalf of somebody else".

X is just the worst *practical* example of this, since not only is it the most common such server, it's also a case where people see interactive issues really easily.

And the problem is that a lot of clients actually end up doing *more* in the X server than they do themselves directly. Doing things like showing a line of text on the screen is a lot more expensive than just keeping track of that line of text, so you end up with the X server easily being marked as getting "too much" CPU time, and the clients as being starved for CPU time. And then you get bad interactive behaviour.

So "good fairness" really should involve some notion of "work done for others". It's just not very easy to do..

So "good fairness" really should involve some notion of "work done for others". It's just not very easy to do..

Quoted 8 lines · Mike Galbraith

Quoted 4 lines · Con Kolivas

Mike the cpu is being proportioned out perfectly according to fairness as I mentioned in the prior email, yet X is getting the lower latency scheduling. I'm not sure within the bounds of fairness what more would you have happen to your liking with this test case?

Quoted 3 lines

It has been said that "perfection is the enemy of good". The two interactive tasks receiving 40% cpu while two niced background jobs receive 60% may well be perfect, but it's damn sure not good.

Well, the real problem is really "server that works on behalf of somebody else".

X is just the worst *practical* example of this, since not only is it the most common such server, it's also a case where people see interactive issues really easily.

And the problem is that a lot of clients actually end up doing *more* in the X server than they do themselves directly. Doing things like showing a line of text on the screen is a lot more expensive than just keeping track of that line of text, so you end up with the X server easily being marked as getting "too much" CPU time, and the clients as being starved for CPU time. And then you get bad interactive behaviour.

So "good fairness" really should involve some notion of "work done for others". It's just not very easy to do..

So "good fairness" really should involve some notion of "work done for others". It's just not very easy to do..

Quoted 3 lines

It has been said that "perfection is the enemy of good". The two interactive tasks receiving 40% cpu while two niced background jobs receive 60% may well be perfect, but it's damn sure not good.

Well, the real problem is really "server that works on behalf of somebody else".

And the problem is that a lot of clients actually end up doing *more* in the X server than they do themselves directly.

Quoted 4 lines · Con Kolivas

Mike the cpu is being proportioned out perfectly according to fairness as I mentioned in the prior email, yet X is getting the lower latency scheduling. I'm not sure within the bounds of fairness what more would you have happen to your liking with this test case?

It has been said that "perfection is the enemy of good". The two interactive tasks receiving 40% cpu while two niced background jobs receive 60% may well be perfect, but it's damn sure not good.

Again I think your test is not a valid testcase. Why use two threads for your encoding with one cpu? Is that what other dedicated desktop OSs would do?

Quoted 2 lines · Con Kolivas

Again I think your test is not a valid testcase. Why use two threads for your encoding with one cpu? Is that what other dedicated desktop OSs would do?

One thought occured to me (shit happens, sometimes): as your scheduler is "strictly fair", won't that enable trivial DoS by just letting an user fork a multitude of CPU-intensive processes ?

Quoted 6 lines · Mike Galbraith

Quoted 4 lines · Con Kolivas

Mike the cpu is being proportioned out perfectly according to fairness as I mentioned in the prior email, yet X is getting the lower latency scheduling. I'm not sure within the bounds of fairness what more would you have happen to your liking with this test case?

Quoted 3 lines

It has been said that "perfection is the enemy of good". The two interactive tasks receiving 40% cpu while two niced background jobs receive 60% may well be perfect, but it's damn sure not good.

Again I think your test is not a valid testcase. Why use two threads for your encoding with one cpu? Is that what other dedicated desktop OSs would do?

And let's not lose sight of things with this one testcase.

RSDL fixes
- every starvation case
- all fairness isssues
- is better 95% of the time on the desktop

If we fix 95% of the desktop and worsen 5% is that bad given how much else we've gained in the process?

Quoted 7 lines · Con Kolivas

Quoted 6 lines · Mike Galbraith

Quoted 4 lines · Con Kolivas

Mike the cpu is being proportioned out perfectly according to fairness as I mentioned in the prior email, yet X is getting the lower latency scheduling. I'm not sure within the bounds of fairness what more would you have happen to your liking with this test case?

Quoted 7 lines

Quoted 3 lines

It has been said that "perfection is the enemy of good". The two interactive tasks receiving 40% cpu while two niced background jobs receive 60% may well be perfect, but it's damn sure not good.

Again I think your test is not a valid testcase. Why use two threads for your encoding with one cpu? Is that what other dedicated desktop OSs would do?

The testcase is perfectly valid. My buddies box has two full cores, so we used two encoders such that whatever bandwidth is not being actively consumed by more important things gets translated into mp3 encoding.

How would you go about ensuring that there won't be any cycles wasted?

_My_ box has 1 core that if fully utilized translates to 1.2 cores.. or whatever, depending on the phase of the moon. But no matter, logical vs physical cpu argument is pure hand-waving. What really matters here is the bottom line: your fair scheduler ignores the very real requirements of interactivity.

Quoted 6 lines

And let's not lose sight of things with this one testcase.

RSDL fixes
- every starvation case
- all fairness isssues
- is better 95% of the time on the desktop

I don't know where you got that 95% number from. For the most part, the existing scheduler does well. If it sucked 95% of the time, it would have been shredded a long time ago.

Quoted 2 lines

If we fix 95% of the desktop and worsen 5% is that bad given how much else we've gained in the process?

Killing the known corner case starvation scenarios is wonderful, but let's not just pretend that interactive tasks don't have any special requirements.

-Mike

Quoted 4 lines · Mike Galbraith

Killing the known corner case starvation scenarios is wonderful, but let's not just pretend that interactive tasks don't have any special requirements.

Now you're really making a stretch of things. Where on earth did I say that interactive tasks don't have special requirements? It's a fundamental feature of this scheduler that I go to great pains to get them as low latency as possible and their fair share of cpu despite having a completely fair cpu distribution.

Quoted 6 lines · Con Kolivas

Quoted 4 lines · Mike Galbraith

Killing the known corner case starvation scenarios is wonderful, but let's not just pretend that interactive tasks don't have any special requirements.

Quoted 5 lines

Now you're really making a stretch of things. Where on earth did I say that interactive tasks don't have special requirements? It's a fundamental feature of this scheduler that I go to great pains to get them as low latency as possible and their fair share of cpu despite having a completely fair cpu distribution.

As soon as your cpu is fully utilized, fairness looses or interactivity loses. Pick one.

Quoted 2 lines · Mike Galbraith

As soon as your cpu is fully utilized, fairness looses or interactivity loses. Pick one.

That's not true unless you refuse to prioritise your tasks accordingly. Let's take this discussion in a different direction. You already nice your lame processes. Why? You already have the concept that you are prioritising things to normal or background tasks. You say so yourself that lame is a background task. Stating the bleedingly obvious, the unix way of prioritising things is via nice. You already do that. So moving on from that...

Your test case you ask "how can I maximise cpu usage". Well you know the answer already. You run two threads. I won't dispute that.

The debate seems to be centered on whether two tasks that are niced +5 or to a higher value is background. In my opinion, nice 5 is not background, but relatively less cpu. You already are savvy enough to be using two threads and nicing them. All I ask you to do when using RSDL is to change your expectations slightly and your settings from nice 5 to nice 10 or 15 or even 19. Why is that so offensive to you?

Please don't pick 5.none of the above. Please try to work with me on this.

Quoted 11 lines · Con Kolivas

Quoted 2 lines · Mike Galbraith

As soon as your cpu is fully utilized, fairness looses or interactivity loses. Pick one.

That's not true unless you refuse to prioritise your tasks accordingly. Let's take this discussion in a different direction. You already nice your lame processes. Why? You already have the concept that you are prioritising things to normal or background tasks. You say so yourself that lame is a background task. Stating the bleedingly obvious, the unix way of prioritising things is via nice. You already do that. So moving on from that...

Sure. If a user wants to do anything interactive, they can indeed nice 19 the rest of their box before they start.

Quoted 9 lines

Your test case you ask "how can I maximise cpu usage". Well you know the answer already. You run two threads. I won't dispute that.

The debate seems to be centered on whether two tasks that are niced +5 or to a higher value is background. In my opinion, nice 5 is not background, but relatively less cpu. You already are savvy enough to be using two threads and nicing them. All I ask you to do when using RSDL is to change your expectations slightly and your settings from nice 5 to nice 10 or 15 or even 19. Why is that so offensive to you?

It's not "offensive" to me, it is a behavioral regression. The situation as we speak is that you can run cpu intensive tasks while watching eye-candy. With RSDL, you can't, you feel the non-interactive load instantly. Doesn't the fact that you're asking me to lower my expectations tell you that I just might have a point?

Quoted 2 lines

Please don't pick 5.none of the above. Please try to work with me on this.

I'm not trying to be pig-headed. I'm of the opinion that fairness is great... until you strictly enforce it wrt interactive tasks.

Quoted 26 lines · Mike Galbraith

Quoted 11 lines · Con Kolivas

Quoted 2 lines · Mike Galbraith

As soon as your cpu is fully utilized, fairness looses or interactivity loses. Pick one.

That's not true unless you refuse to prioritise your tasks accordingly. Let's take this discussion in a different direction. You already nice your lame processes. Why? You already have the concept that you are prioritising things to normal or background tasks. You say so yourself that lame is a background task. Stating the bleedingly obvious, the unix way of prioritising things is via nice. You already do that. So moving on from that...

Sure. If a user wants to do anything interactive, they can indeed nice 19 the rest of their box before they start.

Quoted 9 lines

Your test case you ask "how can I maximise cpu usage". Well you know the answer already. You run two threads. I won't dispute that.

The debate seems to be centered on whether two tasks that are niced +5 or to a higher value is background. In my opinion, nice 5 is not background, but relatively less cpu. You already are savvy enough to be using two threads and nicing them. All I ask you to do when using RSDL is to change your expectations slightly and your settings from nice 5 to nice 10 or 15 or even 19. Why is that so offensive to you?

Quoted 5 lines

It's not "offensive" to me, it is a behavioral regression. The situation as we speak is that you can run cpu intensive tasks while watching eye-candy. With RSDL, you can't, you feel the non-interactive load instantly. Doesn't the fact that you're asking me to lower my expectations tell you that I just might have a point?

Yet looking at the mainline scheduler code, nice 5 tasks are also supposed to get 75% cpu compared to nice 0 tasks, however I cannot seem to get 75% cpu with a fully cpu bound task in the presence of an interactive task. To me that means mainline is not living up to my expectations. What you're saying is your expectations are based on a false cpu expectation from nice
5. You can spin it both ways. It seems to me the only one that lives up to a defined expectation is to be fair. Anything else is at best vague, and at worst starvation prone.

Quoted 3 lines

Quoted 2 lines

Please don't pick 5.none of the above. Please try to work with me on this.

Quoted 2 lines

I'm not trying to be pig-headed. I'm of the opinion that fairness is great... until you strictly enforce it wrt interactive tasks.

How about answering my question then since I offered you numerous combinations of ways to tackle the problem? The simplest one doesn't even need code, it just needs you to alter the nice value that you're already setting.

Quoted 2 lines · Mike Galbraith

I'm not trying to be pig-headed. I'm of the opinion that fairness is great... until you strictly enforce it wrt interactive tasks.

How about answering my question then since I offered you numerous combinations of ways to tackle the problem? The simplest one doesn't even need code, it just needs you to alter the nice value that you're already setting.

Quoted 5 lines · Mike Galbraith

It's not "offensive" to me, it is a behavioral regression. The situation as we speak is that you can run cpu intensive tasks while watching eye-candy. With RSDL, you can't, you feel the non-interactive load instantly. Doesn't the fact that you're asking me to lower my expectations tell you that I just might have a point?

Yet looking at the mainline scheduler code, nice 5 tasks are also supposed to get 75% cpu compared to nice 0 tasks, however I cannot seem to get 75% cpu with a fully cpu bound task in the presence of an interactive task.

To me
that means mainline is not living up to my expectations. What you're saying is your expectations are based on a false cpu expectation from nice 5. You can spin it both ways.

Quoted 5 lines

It's not "offensive" to me, it is a behavioral regression. The situation as we speak is that you can run cpu intensive tasks while watching eye-candy. With RSDL, you can't, you feel the non-interactive load instantly. Doesn't the fact that you're asking me to lower my expectations tell you that I just might have a point?

Yet looking at the mainline scheduler code, nice 5 tasks are also supposed to get 75% cpu compared to nice 0 tasks, however I cannot seem to get 75% cpu with a fully cpu bound task in the presence of an interactive task. [...]

[...] The situation as we speak is that you can run cpu intensive tasks while watching eye-candy. With RSDL, you can't, you feel the non-interactive load instantly. [...]

ps. please be nice to each other - both of you are long-time
scheduler contributors who did lots of cool stuff :-)

Quoted 3 lines · Mike Galbraith

[...] The situation as we speak is that you can run cpu intensive tasks while watching eye-candy. With RSDL, you can't, you feel the non-interactive load instantly. [...]

i have to agree with Mike that this is a material regression that cannot be talked around.

Con, we want RSDL to /improve/ interactivity. Having new scheduler interactivity logic that behaves /worse/ in the presence of CPU hogs, which CPU hogs are even reniced to +5, than the current interactivity code, is i think a non-starter. Could you try to fix this, please? Good interactivity in the presence of CPU hogs (be them default nice level or nice +5) is _the_ most important scheduler interactivity metric. Anything else is really secondary.

Ingo

ps. please be nice to each other - both of you are long-time
scheduler contributors who did lots of cool stuff :-)

Well I guess you must have missed where I asked him if he would be happy if I changed +5 metrics to do whatever he wanted and he refused to answer me. [...]

Quoted 3 lines · Con Kolivas

Well I guess you must have missed where I asked him if he would be happy if I changed +5 metrics to do whatever he wanted and he refused to answer me. [...]

I'd say lets keep nice levels out of this completely for now - while they should work _too_, it's easy because the scheduler has the 'nice' information. The basic behavior of CPU hogs that matters most.

So the question is: if all tasks are on the same nice level, how does, in Mike's test scenario, RSDL behave relative to the current interactivity code?

Ingo

Quoted 3 lines · Ingo Molnar

So the question is: if all tasks are on the same nice level, how does, in Mike's test scenario, RSDL behave relative to the current interactivity code?

The only way to get the same behaviour on RSDL without hacking an interactivity estimator, priority boost cpu misproportionator onto it is to either -nice X or +nice lame.

Quoted 8 lines · Ingo Molnar

Quoted 3 lines · Mike Galbraith

[...] The situation as we speak is that you can run cpu intensive tasks while watching eye-candy. With RSDL, you can't, you feel the non-interactive load instantly. [...]

i have to agree with Mike that this is a material regression that cannot be talked around.

Quoted 7 lines

Con, we want RSDL to /improve/ interactivity. Having new scheduler interactivity logic that behaves /worse/ in the presence of CPU hogs, which CPU hogs are even reniced to +5, than the current interactivity code, is i think a non-starter. Could you try to fix this, please? Good interactivity in the presence of CPU hogs (be them default nice level or nice +5) is _the_ most important scheduler interactivity metric. Anything else is really secondary.

Well I guess you must have missed where I asked him if he would be happy if I changed +5 metrics to do whatever he wanted and he refused to answer me. That would easily fit within that scheme. Any percentage of nice value he chose. I suggest 50% of nice 0. Heck I can even increase it if he likes. All I asked for was an answer as to whether that would satisfy his criterion.

nice on my debian etch seems to choose nice +10 without arguments contrary to a previous discussion that said 4 was the default. However 4 is a good value to use as a base of sorts.

a previous discussion that said 4 was the default...I don't see why. nice uses +10 by default on all linux distro...So I suspect that if Mike just used "nice lame" instead of "nice +5 lame", he would have got what he wanted.

Con, we want RSDL to /improve/ interactivity. Having new scheduler interactivity logic that behaves /worse/ in the presence of CPU hogs, which CPU hogs are even reniced to +5, than the current interactivity code, is i think a non-starter. Could you try to fix this, please? Good interactivity in the presence of CPU hogs (be them default nice level or nice +5) is _the_ most important scheduler interactivity metric. Anything else is really secondary.

I just retested with the encoders at nice 0, and the x/gforce combo is terrible. [...]

[...] Funny thing though, x/gforce isn't as badly affected with a kernel build. Any build is quite noticable, but even at -j8, the effect doen't seem to be (very brief test warning applies) as bad as with only the two encoders running. That seems quite odd.

Quoted 2 lines · Mike Galbraith

I just retested with the encoders at nice 0, and the x/gforce combo is terrible. [...]

ok. So nice levels had nothing to do with it - it's some other regression somewhere. How does the vanilla scheduler cope with the exactly same workload? I.e. could you describe the 'delta' difference in behavior - because the delta is what we are interested in mostly, the 'absolute' behavior alone is not sufficient. Something like:

- on scheduler foo, under this workload, the CPU hogs steal 70% CPU time and the resulting desktop experience is 'choppy': mouse pointer is laggy and audio skips.

- on scheduler bar, under this workload, the CPU hogs are at 40% CPU time and the desktop experience is smooth.

things like that - we really need to be able to see the delta.

Quoted 4 lines

[...] Funny thing though, x/gforce isn't as badly affected with a kernel build. Any build is quite noticable, but even at -j8, the effect doen't seem to be (very brief test warning applies) as bad as with only the two encoders running. That seems quite odd.

likewise, how does the RSDL kernel build behavior compare to the vanilla scheduler's behavior? (what happens in one that doesnt happen in the other, etc.)

Quoted 17 lines · Ingo Molnar

Quoted 2 lines · Mike Galbraith

I just retested with the encoders at nice 0, and the x/gforce combo is terrible. [...]

ok. So nice levels had nothing to do with it - it's some other regression somewhere. How does the vanilla scheduler cope with the exactly same workload? I.e. could you describe the 'delta' difference in behavior - because the delta is what we are interested in mostly, the 'absolute' behavior alone is not sufficient. Something like:

- on scheduler foo, under this workload, the CPU hogs steal 70% CPU time and the resulting desktop experience is 'choppy': mouse pointer is laggy and audio skips.

- on scheduler bar, under this workload, the CPU hogs are at 40% CPU time and the desktop experience is smooth.

Quoted 1 line

things like that - we really need to be able to see the delta.

I only find a slowdown, no choppiness, no audio stutter (it would be extremely hard to make audio stutter in this design without i/o starvation or something along those lines). The number difference in cpu percentage I've already given on the previous email. The graphics driver does feature in this test case as well so others' mileage may vary. Mike said it was terrible.

Quoted 8 lines

Quoted 4 lines

[...] Funny thing though, x/gforce isn't as badly affected with a kernel build. Any build is quite noticable, but even at -j8, the effect doen't seem to be (very brief test warning applies) as bad as with only the two encoders running. That seems quite odd.

likewise, how does the RSDL kernel build behavior compare to the vanilla scheduler's behavior? (what happens in one that doesnt happen in the other, etc.)

Kernel compiles seem similar till the jobs get above about 3 where rsdl gets slower but still smooth. Audio is basically unaffected either way.

Don't forget all the rest of the cases people have posted.

It seems to be a plain linear slowdown. The lurchiness I'm experiencing varies in intensity, and is impossible to quantify. I see neither lurchiness nor slowdown in mainline through -j8.

Mike Galbraith <[email protected]> writes:

[snip]

Quoted 4 lines

It seems to be a plain linear slowdown. The lurchiness I'm experiencing varies in intensity, and is impossible to quantify. I see neither lurchiness nor slowdown in mainline through -j8.

Whaa? make -j8 on mainline makes my desktop box completely useless.

Please reconsider your statement.

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

"Serge" == Serge Belyshev <[email protected]> writes:

Quoted 4 lines

It seems to be a plain linear slowdown. The lurchiness I'm experiencing varies in intensity, and is impossible to quantify. I see neither lurchiness nor slowdown in mainline through -j8.

Quoted 7 lines · Ingo Molnar

Con, we want RSDL to /improve/ interactivity. Having new scheduler interactivity logic that behaves /worse/ in the presence of CPU hogs, which CPU hogs are even reniced to +5, than the current interactivity code, is i think a non-starter. Could you try to fix this, please? Good interactivity in the presence of CPU hogs (be them default nice level or nice +5) is _the_ most important scheduler interactivity metric. Anything else is really secondary.

I just retested with the encoders at nice 0, and the x/gforce combo is terrible. Funny thing though, x/gforce isn't as badly affected with a kernel build. Any build is quite noticable, but even at -j8, the effect doen't seem to be (very brief test warning applies) as bad as with only the two encoders running. That seems quite odd.

Quoted 4 lines

[...] The situation as we speak is that you can run cpu intensive tasks while watching eye-candy. With RSDL, you can't, you feel the non-interactive load instantly. [...]

i have to agree with Mike that this is a material regression that cannot be talked around.

Con, we want RSDL to /improve/ interactivity.

Having new scheduler
interactivity logic that behaves /worse/ in the presence of CPU hogs, which CPU hogs are even reniced to +5, than the current interactivity code, is i think a non-starter. Could you try to fix this, please?

Good
interactivity in the presence of CPU hogs (be them default nice level or nice +5) is _the_ most important scheduler interactivity metric. Anything else is really secondary.

Good interactivity for tasks that aren't themselves CPU hogs. A task should get low latency if and only if it's yielding the CPU voluntarily most of the time. If it's not, it can only get better interactivity at the cost of fairness, and you have to *ask* for that. (Common sense says you can't give a task *more* CPU because it yields the CPU a lot. And how else do you determine interactivity other than nice level?)

This scheduler will not give you greater interactivity at the cost of fairness unless you really ask for it. I think that's a good thing, though I do agree it might take some getting used to.

There's a distinction between giving it more cpu and giving it higher
priority: the important part about having high priority is getting low latency access to the cpu when its needed.

This really seems like the wrong approach to me. The implication here and in other mails is that fairness is an inherently good thing which should obviously take preference over any other property.

The old unix-style dynamic priority scheme was designed to give interactive processes high priorities, by using the observation that "interactive" means "spends a lot of time blocked waiting for input". That model of interactive is way too simple now, and the attempts to try an find an equivalent heuristic have been flawed and lead to - in some cases - wildly bad behaviours. I'm guessing the emphasis on "fairness" is in reaction to this, which is fair enough.

But saying that the user needs to explicitly hold the schedulers hand and nice everything to tell it how to schedule seems to be an abdication of duty, an admission of failure. We can't expect users to finesse all their processes with nice, and it would be a bad user interface to ask them to do so.

And if someone/distro *does* go to all the effort of managing how to get all the processes at the right nice levels, you have this big legacy problem where you're now stuck keeping all those nice values meaningful as you continue to develop the scheduler. Its bad enough to make them do the work in the first place, but its worse if they need to make it a kernel version dependent function.

Quoted 4 lines

There's a distinction between giving it more cpu and giving it higher
priority: the important part about having high priority is getting low latency access to the cpu when its needed.

I agree. Tasks that voluntarily relinquish their timeslices should get lower latency compared to other processes at the same static priority.

Quoted 4 lines

This really seems like the wrong approach to me. The implication here and in other mails is that fairness is an inherently good thing which should obviously take preference over any other property.

Yes, that is the implication. The alternative to fairness is arbitrary unfairness. "Rational unfairness" is a form of fairness.

Quoted 8 lines

The old unix-style dynamic priority scheme was designed to give interactive processes high priorities, by using the observation that "interactive" means "spends a lot of time blocked waiting for input". That model of interactive is way too simple now, and the attempts to try an find an equivalent heuristic have been flawed and lead to - in some cases - wildly bad behaviours. I'm guessing the emphasis on "fairness" is in reaction to this, which is fair enough.

I don't think it makes sense for the scheduler to look for some hint that the user would prefer a task to get more CPU and try to give it more. That's what 'nice' is for.

Quoted 6 lines

But saying that the user needs to explicitly hold the schedulers hand and nice everything to tell it how to schedule seems to be an abdication of duty, an admission of failure. We can't expect users to finesse all their processes with nice, and it would be a bad user interface to ask them to do so.

Then you will always get cases where the scheduler does not do what the user wants because the scheduler does not *know* what the user wants. You always have to tell a computer what you want it to do, and the best it can do is faithfully follow your request.

I think it's completely irrational to ask for a scheduler that automatically gives more CPU time to CPU hogs.

I agree. I'm not claiming to have the perfect solution. Let's not let the perfect be the enemy of the good though.

David Schwartz wrote:
Hm, well. The general preference has been for the kernel to do a good-enough job on getting the common cases right without tuning, and then only add knobs for the really tricky cases it can't do well. But the impression I'm getting here is that you often get sucky behaviours without tuning.

Quoted 3 lines

I think it's completely irrational to ask for a scheduler that automatically gives more CPU time to CPU hogs.

Well, it doesn't have to. It could give good low latency with short timeslices to things which appear to be interactive. If the interactive program doesn't make good use of its low latency, then it will suck. But that's largely independent of how much overall CPU you give it.

Quoted 2 lines

I agree. I'm not claiming to have the perfect solution. Let's not let the perfect be the enemy of the good though.

For all its faults, the current scheduler mostly does a good job without much tuning - I normally only use "nice" to run cpu-bound things without jacking the cpu speed up. Certainly in my normal interactive use of compiz vs make -j4 on a dual-core generally gets pretty pretty good results. I plan on testing the new scheduler soon though.

Quoted 5 lines

But saying that the user needs to explicitly hold the schedulers hand and nice everything to tell it how to schedule seems to be an abdication of duty, an admission of failure. We can't expect users to finesse all their processes with nice, and it would be a bad user interface to ask them to do so.

Then you will always get cases where the scheduler does not do what the user wants because the scheduler does not *know* what the user wants. You always have to tell a computer what you want it to do, and the best it can do is faithfully follow your request.

I think it's completely irrational to ask for a scheduler that automatically gives more CPU time to CPU hogs.

Quoted 6 lines

And if someone/distro *does* go to all the effort of managing how to get all the processes at the right nice levels, you have this big legacy problem where you're now stuck keeping all those nice values meaningful as you continue to develop the scheduler. Its bad enough to make them do the work in the first place, but its worse if they need to make it a kernel version dependent function.

I agree. I'm not claiming to have the perfect solution. Let's not let the perfect be the enemy of the good though.

Quoted 11 lines

Quoted 1 line

Quoted 1 line

Killing the known corner case starvation scenarios

is wonderful, but

Quoted 1 line

Quoted 1 line

let's not just pretend that interactive tasks don't

have any special

Quoted 3 lines

Quoted 1 line

requirements.

Now you're really making a stretch of things. Where

on earth did I say that

Quoted 1 line

interactive tasks don't have special requirements?

It's a fundamental feature

Quoted 1 line

of this scheduler that I go to great pains to get

Quoted 8 lines

them as low latency as

Quoted 1 line

possible and their fair share of cpu despite having a

completely fair cpu

Quoted 1 line

distribution.

As soon as your cpu is fully utilized, fairness looses or interactivity
loses. Pick one.

That's not true unless you refuse to prioritise your tasks
accordingly. Let's take this discussion in a different direction. You
already nice your lame processes. Why? You already have the concept
that you are prioritising things to normal or background tasks. You
say so yourself that lame is a background task. Stating the bleedingly
obvious, the unix way of prioritising things is via nice. You already
do that. So moving on from that...

Your test case you ask "how can I maximise cpu usage". Well you know
the answer already. You run two threads. I won't dispute that.

The debate seems to be centered on whether two tasks that are niced +5
or to a higher value is background. In my opinion, nice 5 is not
background, but relatively less cpu. You already are savvy enough to
be using two threads and nicing them. All I ask you to do when using
RSDL is to change your expectations slightly and your settings from
nice 5 to nice 10 or 15 or even 19. Why is that so offensive to you?
nice 5 is 75% the cpu of nice 0. nice 10 is 50%, nice 15 is 25%, nice

Quoted 6 lines · Con Kolivas

Quoted 4 lines · Mike Galbraith

Killing the known corner case starvation scenarios is wonderful, but let's not just pretend that interactive tasks don't have any special requirements.

Quoted 5 lines

Now you're really making a stretch of things. Where on earth did I say that interactive tasks don't have special requirements? It's a fundamental feature of this scheduler that I go to great pains to get them as low latency as possible and their fair share of cpu despite having a completely fair cpu distribution.

As soon as your cpu is fully utilized, fairness looses or interactivity loses. Pick one.

the problem comes when this isn't enough. if you have several CPU hogs on a system, and they are all around the same priority level, how can the scheduler know which one needs the CPU the most for good interactivity?

in some cases you may be able to directly detect that your high-priority process is waiting for another one (tracing pipes and local sockets for example), but what if you are waiting for several of them? (think a multimedia desktop waiting for the sound card, CDRom, hard drive, and video all at once) which one needs the extra CPU the most?

Quoted 9 lines · David Lang

the problem comes when this isn't enough. if you have several CPU hogs on a system, and they are all around the same priority level, how can the scheduler know which one needs the CPU the most for good interactivity?

in some cases you may be able to directly detect that your high-priority process is waiting for another one (tracing pipes and local sockets for example), but what if you are waiting for several of them? (think a multimedia desktop waiting for the sound card, CDRom, hard drive, and video all at once) which one needs the extra CPU the most?

I'm not an expert in this area by any means but after reading this thread the OSX solution of simply telling the kernel "I'm the GUI, schedule me accordingly" looks increasingly attractive. Why make the kernel guess when we can just be explicit?

Does anyone know of a UNIX-like system that has managed to solve this problem without hooking the GUI into the scheduler?

Lee

Quoted 6 lines

Quoted 2 lines

If we fix 95% of the desktop and worsen 5% is that bad given how much else we've gained in the process?

Killing the known corner case starvation scenarios is wonderful, but let's not just pretend that interactive tasks don't have any special requirements.

Now you're really making a stretch of things. Where on earth did I say that interactive tasks don't have special requirements? It's a fundamental feature of this scheduler that I go to great pains to get them as low latency as possible and their fair share of cpu despite having a completely fair cpu distribution.

Quoted 22 lines · Mike Galbraith

Quoted 7 lines · Con Kolivas

Quoted 6 lines · Mike Galbraith

Quoted 4 lines · Con Kolivas

Mike the cpu is being proportioned out perfectly according to fairness as I mentioned in the prior email, yet X is getting the lower latency scheduling. I'm not sure within the bounds of fairness what more would you have happen to your liking with this test case?

Quoted 7 lines

Quoted 3 lines

It has been said that "perfection is the enemy of good". The two interactive tasks receiving 40% cpu while two niced background jobs receive 60% may well be perfect, but it's damn sure not good.

Again I think your test is not a valid testcase. Why use two threads for your encoding with one cpu? Is that what other dedicated desktop OSs would do?

The testcase is perfectly valid. My buddies box has two full cores, so we used two encoders such that whatever bandwidth is not being actively consumed by more important things gets translated into mp3 encoding.

How would you go about ensuring that there won't be any cycles wasted?

Quoted 5 lines

_My_ box has 1 core that if fully utilized translates to 1.2 cores.. or whatever, depending on the phase of the moon. But no matter, logical vs physical cpu argument is pure hand-waving. What really matters here is the bottom line: your fair scheduler ignores the very real requirements of interactivity.

Definitely not. It does not give unfair cpu towards interactive tasks. That's a very different argument.

Quoted 7 lines

Quoted 6 lines

And let's not lose sight of things with this one testcase.

RSDL fixes
- every starvation case
- all fairness isssues
- is better 95% of the time on the desktop

Quoted 3 lines

I don't know where you got that 95% number from. For the most part, the existing scheduler does well. If it sucked 95% of the time, it would have been shredded a long time ago.

Check the number of feedback reports. I don't feel petty enough to count them personally to give you an accuracte percentage.

Quoted 6 lines

Quoted 2 lines

If we fix 95% of the desktop and worsen 5% is that bad given how much else we've gained in the process?

Killing the known corner case starvation scenarios is wonderful, but let's not just pretend that interactive tasks don't have any special requirements.

Now you're really making a stretch of things. Where on earth did I say that interactive tasks don't have special requirements? It's a fundamental feature of this scheduler that I go to great pains to get them as low latency as possible and their fair share of cpu despite having a completely fair cpu distribution.

Considering the concepts put out by projects such as BOINC and SETI@Home, I wouldn't be thoroughly surprised by this ideology, although I do question the particular way this test case is being run.

This seems to me like he's saying that there has to be a mechanism (outside of nice) that can be used to treat processes that "I" want to be interactive all special-like. It feels like something that would have been said in the design of what the scheduler was in -ck and is currently in vanilla.

To me, that fundamentally clashes with the design behind RSDL. That said, I could be wrong -- Con appears to have something that could be very promising up his sleeve that could come out sooner or later. Once he's written it, of course. In any case, RSDL seems very promising, for the most part.

Perhaps, Mike Galbraith, do you feel that it should be possible to use the CPU at 100% for some task and still maintain excellent interactivity?

That said, I haven't run the test case in particular yet, although I will see if I can get the time to do so soon. In any case, I personally do have a few qualms about this test case being run on HT virtual cores:

Virtual or physical cores has nothing to do with the interactivity regression I noticed. Two nice 0 tasks which combined used 50% of my box can no longer share that box with two nice 5 tasks and receive the 50% they need to perform. That's it. From there, we wandered off into a discussion on the relative merit and pitfalls of fairness.

-Mike

Quoted 5 lines · Mike Galbraith

Virtual or physical cores has nothing to do with the interactivity regression I noticed. Two nice 0 tasks which combined used 50% of my box can no longer share that box with two nice 5 tasks and receive the 50% they need to perform. That's it. From there, we wandered off into a discussion on the relative merit and pitfalls of fairness.

And again, with X in its current implementation it is NOT like two nice 0 tasks at all; it is like one nice 0 task. This is being fixed in the X design as we speak.

How would you go about ensuring that there won't be any cycles wasted?

Killing the known corner case starvation scenarios is wonderful, but let's not just pretend that interactive tasks don't have any special requirements.

Quoted 6 lines

And let's not lose sight of things with this one testcase.

RSDL fixes
- every starvation case
- all fairness isssues
- is better 95% of the time on the desktop

I don't know where you got that 95% number from. For the most part, the existing scheduler does well. If it sucked 95% of the time, it would have been shredded a long time ago.

Mike Galbraith <[email protected]> writes:

[snip]

Quoted 11 lines

Quoted 6 lines

And let's not lose sight of things with this one testcase.

RSDL fixes
- every starvation case
- all fairness isssues
- is better 95% of the time on the desktop

I don't know where you got that 95% number from. For the most part, the existing scheduler does well. If it sucked 95% of the time, it would have been shredded a long time ago.

I tell you.

http://article.gmane.org/gmane.linux.kernel/500027
http://article.gmane.org/gmane.linux.kernel/502996
http://article.gmane.org/gmane.linux.kernel/500119
http://article.gmane.org/gmane.linux.kernel/500784
http://article.gmane.org/gmane.linux.kernel/500768
http://article.gmane.org/gmane.linux.kernel/502255
http://article.gmane.org/gmane.linux.kernel/502282
http://article.gmane.org/gmane.linux.kernel/503650
http://article.gmane.org/gmane.linux.kernel/503695
http://article.gmane.org/gmane.linux.kernel.ck/6512
http://article.gmane.org/gmane.linux.kernel.ck/6539
http://article.gmane.org/gmane.linux.kernel.ck/6565

Quoted 5 lines · Mike Galbraith

The test scenario was one any desktop user might do with every expectation responsiveness of the interactive application remain intact. I understand the concepts here Con, and I'm not knocking your scheduler. I find it to be a step forward on the one hand, but a step backward on the other.

ok, then that step backward needs to be fixed.

Quoted 2 lines · Mike Galbraith

Hmm. So... anything that's client/server is going to suffer horribly unless niced tasks are niced all the way down to 19?

Fortunately most client server models dont usually have mutually exclusive cpu use like this X case. There are many things about X that are still a little (/me tries to think of a relatively neutral term)... wanting. :(

Quoted 4 lines · Con Kolivas

Quoted 2 lines · Mike Galbraith

Hmm. So... anything that's client/server is going to suffer horribly unless niced tasks are niced all the way down to 19?

Quoted 4 lines

Fortunately most client server models dont usually have mutually exclusive cpu use like this X case. There are many things about X that are still a little (/me tries to think of a relatively neutral term)... wanting. :(

I'd say the problem is less with X than with Xlib, which is heavily round-trip-based. Fortunately XCB (its successor) seeks to be more asynchronous.

Xav

Quoted 5 lines · Xavier Bestel

Quoted 4 lines · Con Kolivas

Quoted 2 lines · Mike Galbraith

Hmm. So... anything that's client/server is going to suffer horribly unless niced tasks are niced all the way down to 19?

Quoted 8 lines

Quoted 4 lines

Fortunately most client server models dont usually have mutually exclusive cpu use like this X case. There are many things about X that are still a little (/me tries to think of a relatively neutral term)... wanting. :(

I'd say the problem is less with X than with Xlib, which is heavily round-trip-based. Fortunately XCB (its successor) seeks to be more asynchronous.

Yes I recall a talk by Keith Packard on Xorg development and how a heck of a lot of time spent spinning by X (?Xlib) for no damn good reason was the number one thing that made X suck and basically it was silly to try and fix that at the cpu scheduler level since it needed to be corrected in X, and was being actively addressed. So we should stop trying to write cpu schedulers for X.

Quoted 2 lines

Xav

with latest xorg, xlib will be using xcb internally,

Quoted 2 lines · Kasper Sandberg

with latest xorg, xlib will be using xcb internally,

Out of curiosity, when is this "latest" Xorg going to escape to distros,

and is it far enough along that beta testers can gather usable numbers?

Quoted 7 lines · [email protected] wrote:

Quoted 2 lines · Kasper Sandberg

with latest xorg, xlib will be using xcb internally,

Out of curiosity, when is this "latest" Xorg going to escape to distros,

Already is .. Xorg 7.2+ libx11 build with xcb enabled..

Just a couple of questions;

The X/Gforce case; do they alternate cpu between them? By that I mean when they're the only thing running does the cpu load summate to 1 or does it summate to 2?

Gforce presumably is a 3d visualisation? Do you use one of the graphics card drivers listed that uses yield?

Hi Con,

Quoted 9 lines · Con Kolivas

What follows this email is a patch series for the latest version of the RSDL cpu scheduler (ie v0.29). I have addressed all bugs that I am able to reproduce in this version so if some people would be kind enough to test if there are any hidden bugs or oops lurking, it would be nice to know in anticipation of putting this back in -mm. Thanks.

Full patch for 2.6.21-rc3-mm2:
http://ck.kolivas.org/patches/staircase-deadline/2.6.21-rc3-mm2-rsdl-0
.29.patch

I'm seeing a cpu distribution problem running this on my P4 box.

Scenario:
listening to music collection (mp3) via Amarok. Enable Amarok visualization gforce, and size such that X and gforce each use ~50% cpu. Start rip/encode of new CD with grip/lame encoder. Lame is set to use both cpus, at nice 5. Once the encoders start, they receive considerable more cpu than nice 0 X/Gforce, taking ~120% and leaving the remaining 80% for X/Gforce and Amarok (when it updates it's ~12k entry database) to squabble over.

With 2.6.21-rc3, X/Gforce maintain their ~50% cpu (remain smooth), and the encoders (100%cpu bound) get whats left when Amarok isn't eating it.

I plunked the above patch into plain 2.6.21-rc3 and retested to eliminate other mm tree differences, and it's repeatable. The nice 5 cpu hogs always receive considerably more that the nice 0 sleepers.

-Mike

On Sunday 11 March 2007, Mike Galbraith wrote:

Just to comment, I've been running one of the patches between 20-ck1 and this latest one, which is building as I type, but I also run gkrellm here, version 2.2.9.

Since I have been running this middle of this series patch, something is killing gkrellm about once a day, and there is nothing in the logs to indicate a problem. I see a blink out of the corner of my eye, and its gone. And it always starts right back up from a kmenu click.

No idea if anyone else is experiencing this or not.

--
Cheers, Gene

Quoted 11 lines · Gene Heskett

On Sunday 11 March 2007, Mike Galbraith wrote:

Just to comment, I've been running one of the patches between 20-ck1 and this latest one, which is building as I type, but I also run gkrellm here, version 2.2.9.

Since I have been running this middle of this series patch, something is killing gkrellm about once a day, and there is nothing in the logs to indicate a problem. I see a blink out of the corner of my eye, and its gone. And it always starts right back up from a kmenu click.

Quoted 4 lines

No idea if anyone else is experiencing this or not.

--
Cheers, Gene

I've had such an issue with 0.20 or something. Sometimes, the xfce4-panel would disappear (die) when I displayed its menu. Very rare issue.

Doesn't happen with 0.28 anyway. :-) Which looks really good, though I'll update to 0.30.

Quoted 17 lines · Radoslaw Szkodzinski

Quoted 11 lines · Gene Heskett

On Sunday 11 March 2007, Mike Galbraith wrote:

Just to comment, I've been running one of the patches between 20-ck1 and this latest one, which is building as I type, but I also run gkrellm here, version 2.2.9.

Since I have been running this middle of this series patch, something is killing gkrellm about once a day, and there is nothing in the logs to indicate a problem. I see a blink out of the corner of my eye, and its gone. And it always starts right back up from a kmenu click.

Quoted 4 lines

No idea if anyone else is experiencing this or not.

--
Cheers, Gene

Quoted 6 lines

I've had such an issue with 0.20 or something. Sometimes, the xfce4-panel would disappear (die) when I displayed its menu. Very rare issue.

Doesn't happen with 0.28 anyway. :-) Which looks really good, though I'll update to 0.30.

And I didn't see it for the few hours I was booted to 21-rc3-rsdl-0.29, but tar sure went berzackers.

To Con, I knew 2.6.20 worked with your earlier patches, so rather than revert all the way, I just rebooted to 2.6.20.2-rdsl-0.30 and I'm going to fire off another backup. I suspect it will work, but will advise the next time I wake up.

Quoted 4 lines · Gene Heskett

To Con, I knew 2.6.20 worked with your earlier patches, so rather than revert all the way, I just rebooted to 2.6.20.2-rdsl-0.30 and I'm going to fire off another backup. I suspect it will work, but will advise the next time I wake up.

After posting the above, I thought maybe I'd hit a target in the middle and build a 2.6.20.2, with your -0.30 patch, but...

I'm going to have to build a 2.6.20.2, because with the rdsl-0.30 patch, its going to do a level 2 on my /usr/movies directory, which hasn't been touched in 90 days and has about 8.1GB in it according to du, and its going to do nearly all of it. It shouldn't be anything but a directory listing file. But this is what amstatus is reporting:
coyote:/usr/movies 2 7271m dumping 793m ( 10.91%)
(7:26:00)

And its also reporting far more data than exists it seems. As is du, for /var, which might have 2 gigs, its claiming 3.7!

Honest folks, I'm not smoking anything, I quit 18 years ago. Back to bed while this one bombs out too.

--
Cheers, Gene

Quoted 20 lines · Gene Heskett

Quoted 4 lines · Gene Heskett

To Con, I knew 2.6.20 worked with your earlier patches, so rather than revert all the way, I just rebooted to 2.6.20.2-rdsl-0.30 and I'm going to fire off another backup. I suspect it will work, but will advise the next time I wake up.

After posting the above, I thought maybe I'd hit a target in the middle and build a 2.6.20.2, with your -0.30 patch, but...

I'm going to have to build a 2.6.20.2, because with the rdsl-0.30 patch, its going to do a level 2 on my /usr/movies directory, which hasn't been touched in 90 days and has about 8.1GB in it according to du, and its going to do nearly all of it. It shouldn't be anything but a directory listing file. But this is what amstatus is reporting:
coyote:/usr/movies 2 7271m dumping 793m ( 10.91%)
(7:26:00)

And its also reporting far more data than exists it seems. As is du, for /var, which might have 2 gigs, its claiming 3.7!

Quoted 5 lines

Honest folks, I'm not smoking anything, I quit 18 years ago. Back to bed while this one bombs out too.

--
Cheers, Gene

Gene your last good kernel you said was 2.6.20 based. I don't see a good reason even to use 2.6.20.2 as a base given that information.

--
-ck

Quoted 21 lines · Con Kolivas

Quoted 20 lines · Gene Heskett

Quoted 4 lines · Gene Heskett

To Con, I knew 2.6.20 worked with your earlier patches, so rather than revert all the way, I just rebooted to 2.6.20.2-rdsl-0.30 and I'm going to fire off another backup. I suspect it will work, but will advise the next time I wake up.

After posting the above, I thought maybe I'd hit a target in the middle and build a 2.6.20.2, with your -0.30 patch, but...

I'm going to have to build a 2.6.20.2, because with the rdsl-0.30 patch, its going to do a level 2 on my /usr/movies directory, which hasn't been touched in 90 days and has about 8.1GB in it according to du, and its going to do nearly all of it. It shouldn't be anything but a directory listing file. But this is what amstatus is reporting:
coyote:/usr/movies 2 7271m dumping 793m ( 10.91%)
(7:26:00)

And its also reporting far more data than exists it seems. As is du, for /var, which might have 2 gigs, its claiming 3.7!

Quoted 8 lines

Quoted 5 lines

Honest folks, I'm not smoking anything, I quit 18 years ago. Back to bed while this one bombs out too.

--
Cheers, Gene

Gene your last good kernel you said was 2.6.20 based. I don't see a good reason even to use 2.6.20.2 as a base given that information.

I have 2.6.20.1 building now. I know that 2.6.20-ck1 worked well, so now I walking fwd from 2.6.20, trying to bisect it. .1 wasn't much of a patch, but who knows at this point, I'm not 'the shadow' in a 65 year old radio show. And it looks like that build is done, so here goes the next test.

The worst thing about this is that amanda's database is being hosed everytime this happens, and it's been 3 runs in a row, in a dumpcycle of 5, where this has occurred. I can do one more bad run by pre-clearing the vtape +1 that's it is going to use each time because the partition being used for vtapes is sitting at about 93% utilization now. Normal life, its about 84%, it is a 175GB partition. That also is stirring around in the old girls database when I kill stuff she thinks is there, but its also about 3 dumpcycles back and pretty much out of the picture so she will recover in a couple of dumpcycles once I find this, if indeed I do.

You've cooked up patches for all this, so it 2.6.20.1 works ok, then I try your patch on that one. I tried 2.6.21-rc1, and it bombed too, but I just figured that was an -rc1, and we're expected to lose a pint of blood at most any -rc1 aren't we?, so I didn't give it any great thought and reverted till -rc2 came out. But I ramble & times-a-wasting.

Quoted 2 lines

--
-ck