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/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
