Ingo Molnar wrote: >> Anyone who thinks that there exists only two kinds of code: 100% correct >> and 100% incorrect with no shades of grey inbetween is in reality a sort >> of an extremist: whom, depending on mood and affection, we could call >> either a 'coding purist' or a 'coding taliban' ;-)
On Tue, Apr 17, 2007 at 07:29:00PM +0300, Al Boldi wrote: > I am not sure what you mean by this?!? > It's probably well known that nothing is perfect, even if you tried, but to > use this to excuse sub-optimal coding sounds rather lame. > Now, admitting that everything may be fixable, would have been a much more > reasonable response. I don't need this sort of help. I wasn't even all that interested in having it acknowledged as a cfs lacuna, but rather a common design goal across all scheduler implementations with a standardized semantics. Granted, some of my insistence was intended as a hint about what might not be working very well, but I was rather far from wanting to suggest such things, hence the initial avoidance of even mentioning whatever issues cfs' current incarnation in particular might have directly. I rather wanted some statement of the eventual intention, along with some consensus as to what scheduler implementations in general should also use as their objective for nice semantics. With that in hand, it would be made possible to track the progress of cfs in that particular area, and also make direct comparisons against other schedulers attempting to implement the same prioritization semantics. A less abstract statement about this would be that I wanted to hear "This is what should be going on in the area of prioritization in terms of nice levels. We can get yardsticks to measure how schedulers are doing in this area from this." How cfs' current implementation did was a secondary concern apart from using the issue as a hint about what there might be to patch up. The whole reason for resorting to hints instead of going on about nice level support being weak directly was precisely to avoid making the kind of statement you're making. I'm not in the business of shooting down scheduler implementations. I furthermore expect cfs to be useful to people regardless of whether it "pans out" in terms of mainline acceptance, just as many of the other out-of-tree schedulers are; if it should hit mainline, so be it, as it's a technical improvement over epoch expiry semantics regardless. Also, AFAICS honoring nice levels isn't a fundamental issue with the design. Adjusting the sorting key calculation, which doesn't affect the overall design at all, should suffice IMHO. This is also quite far from what you suggest in terms of the gravity of the issue. While I have my own disagreements with the response, it's best to take it at face value instead of the sort of interpretation you're doing. -- wli - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
