| |||||||||||||
RDSL and ignoring feedbackRDSL and ignoring feedbackPosted Jul 26, 2007 14:40 UTC (Thu) by nevyn (subscriber, #33129)In reply to: RDSL and ignoring feedback by corbet Parent article: Still waiting for swap prefetch
That is a very bad analogy, for a "fair" scheduler change requests along the lines of "app. X does Y, and gets an unfair amount of CPU" and should be dealt with promptly. Change requests like "app. X does Y, and I want it to get an unfair amount of CPU" should be solved another way. We didn't drop SELinux because random uid=0 processes could no longer re-write my /etc/shadow file, because that was a desired result.
Looking at it another way if you create holes in the algo. so that Xorg can walk through them, then so can any other piece of code. The correct fix was pointed out, if Xorg needs more CPU time than "normal" then just tell the kernel that using the interfaces specially for that purpose (Ie. nice).
IMNSHO CFS got into the kernel because Ingo wrote it, and basically no other reason. That's not entirely a bad thing, but it's not entirely a good thing either and doing "unbiased" reporting pretending otherwise isn't helping anyone.
(Log in to post comments)
RDSL and ignoring feedback Posted Jul 26, 2007 17:38 UTC (Thu) by erwbgy (subscriber, #4104) [Link] "unbiased" reporting pretending otherwise isn't helping anyone. Of course it is not unbiased reporting - we pay good money for Jon's opinion. That's what an editorial is. Jon explained quite clearly, and even-handedly in my opinion, why he came to the conclusion he did. Agree with him or not (and I certainly don't always), but criticising his reporting because you don't agree with his conclusions is not helping anyone.
RDSL and ignoring feedback Posted Jul 26, 2007 18:26 UTC (Thu) by nevyn (subscriber, #33129) [Link] Maybe that sounded worse that I wanted it to. I didn't mean that Jon was biased against my view point, quite the opposite, it seemed more like he'd tried to "present both sides of an argument" instead of just saying what he thought was right.
But maybe he really did/does believe that the "reported problem" was a regression and needed fixing, at which point I guess I'll just have to disagree.
RDSL and ignoring feedback Posted Jul 27, 2007 21:41 UTC (Fri) by jospoortvliet (subscriber, #33164) [Link] Indeed. Top be honest, I don't get it why he re-stated that. I mean, it'slovely to try and fix things if they come up, but this was and is impossible to fix. And I'm sure Ingo won't try to fix it either. If someone complains X gets not enough CPU (because it gets 1/10th if 10 heavy processes are running), he will tell the person to renice X. Just like Con did. After all, it's what a fair scheduler does.
Someone complaining about it simply doesn't understand it - a fair
BTW not to say Corbet is stupid or anything negatively, I just think he's
RDSL and ignoring feedback Posted Jul 27, 2007 21:51 UTC (Fri) by corbet (editor, #1) [Link] If somebody's workload works on 2.6.N, but fails on 2.6.N+1, it's a regression. It doesn't matter if life is better for a lot of other folks, or whether you call it "fair," it's still a regression. Regressions are bad news. And yes, CFS does do a better job with that sort of workload.
RDSL and ignoring feedback Posted Jul 27, 2007 22:21 UTC (Fri) by zlynx (subscriber, #2285) [Link] It may technically be a regression for that user, but if a change improves things for more other users than it hurts, I call that progress.
It may be a case of two steps forward, one step back, but still progress and a good thing, not bad news.
Regressions and progress Posted Jul 27, 2007 22:41 UTC (Fri) by corbet (editor, #1) [Link] Here's a message from Linus from a couple of weeks ago; I had considered it for the quote of the week:So we don't fix bugs by introducing new problems. That way lies madness, and nobody ever knows if you actually make any real progress at all. Is it two steps forwards, one step back, or one step forward and two steps back? Different people will give different answers.
Regressions and progress Posted Jul 27, 2007 23:37 UTC (Fri) by zlynx (subscriber, #2285) [Link] Linus' statement says regressions are much more important. But that doesn't specify how much more important. And when the benefits of the change build up, they override how important a regression is.
Ingo's scheduler does not work as well as Con's on many 3D applications, like games. That's a regression from Con's work. Ingo's doesn't always schedule games as well as mainline either (Transgaming went to some work to make Cedega share work between processes and sleep enough to fake out the 2.6 scheduler).
If I decide to complain about the regression (which I won't) should Linus hold up merging CFS until Ingo can meet my demand that the new thing work just like the old thing? (Renicing Cedega is just *too* hard! Poor me!)
Another example: I've complained that 4K stacks aren't ready to be the default (stacking enough device mappers crash), but I strongly suspect that the kernel is going to change the default to 4K no matter what I think.
Regressions and progress Posted Oct 9, 2007 21:57 UTC (Tue) by Blaisorblade (guest, #25465) [Link] This Linus quote is also from a couple of years ago, about drivers (when somebody fixed ACPI and broke suspend for most stuff). And he's a maintainer, and he must have this opinion (or the community should replace him).
What matters is "how deep do you need to stack DM" (is it a real problem) and "4k is a default (other choices are kept, so *you* will make the 8k choice, which is mostly worse)".
That is a known problem since years, and Device Mapper can be changed to be non-recursive; see the LWN articles about changes in link-resolution from recursive to iterative to understand what I mean - that's the same stuff. Technically, this is a tail-call optimization to reduce stack depth.
After reading the discussion over Con's community management, and thinking to Reiser4, I think that Linux is not about politics, but about communities, or rather Social Networks of developers and their influence on community filtering they do (that's a lot of academic buzzwords).
That said, it's known that many problem (including VM and I think scheduling) are computationally hard, so whichever solution you choose it has weak points (it's a theorem in some cases - you can prove that for each compressor there is a file the compressor expands). The point is how hard is the regression.
Distributions had to be fixed not to renice X to -10 (as usual for 2.4) when 2.6 came out. A stable kernel cannot require such a big change. I can fix my X startup script (well, working my way through X startup is not fun, even for an experienced Linux developer like me), but the Ubuntu average user cannot (I know tens of such users, switching from Windows because Vista sucks and Linux had Beryl - they are good Physics students).
RDSL and ignoring feedback Posted Jul 28, 2007 12:08 UTC (Sat) by jospoortvliet (subscriber, #33164) [Link] I find that hard to believe if we're talking about the same personcomplaining. His problem can never be fixed by CFS, unless CFS automatically would renice his X, or would introduce unfairness some other way.
CFS will cause regressions, because it doesn't do unfair scheduling -
Besides, CFS does worse on 3D gaming compared to SD and mainline, and ppl
Note that I'm happy CFS got in mainline, as far as I can tell, it has a
Maybe this is worth reading, if you didn't already.
|
|||||||||||||