lkml.org 
[lkml]   [2007]   [Apr]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [Announce] [patch] Modular Scheduler Core and Completely Fair
    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 majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2007-04-17 23:49    [W:0.024 / U:1.508 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site