lkml.org 
[lkml]   [2005]   [Feb]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [Lse-tech] [PATCH] cpusets - big numa cpu and memory placement

    >> As best as I can figure out, CKRM is a fair share scheduler with a
    >> gussied up more modular architecture, so that the components to track
    >> usage, control (throttle) tasks, and classify tasks are separate
    >> plugins.

    > I'm not an expert on CKRM, so I'll leave the refuting (or notrefuting)
    > of your claims as to CKRM's usefulness to someone with more background
    > and expertise on the subject. Anyone want to pipe up and defend the
    > alleged "gussied up" fair-share scheduler?

    Well, I'm not sure I want to minutely examine Paul's choice of words !
    I would have thought that two OLS and one KS presentation would suffice
    to clarify what CKRM is and isn't but that doesn't seem to be the case
    :-) So here we go again

    CKRM is both a resource management infrastructure AND
    a set of controllers. The two are independent.

    The infrastructure provides for
    a) grouping of kernel objects (currently only tasks & sockets but can be
    extended to any others)
    b) an external interface for manipulating attributes of the grouping
    such as shares, statistics and members
    c) an internal interface for controllers to exploit this grouping
    information in whatever way it wants.

    The controllers do whatever they want with the grouping info.
    The IBM folks on the project have written ONE set of controllers for
    cpu, mem, io, net and numtasks which HAPPENS to be/aspire to be
    fair-share. Others are free to write ones which ignore share settings
    and be unfair, callous or whatever else they want.

    We would love to have people write alternate controllers for the same
    resources (cpu,mem,io,net,numtasks) and others. The former will provide
    alternatives to our implementation, the latter will validate the
    architecture's utility.


    >> I can find no significant and useful overlap on any of these
    >> fronts, either the existing plugins or their infrastructure, with what
    >> cpusets has and needs.
    >> There are claims that CKRM has some generalized resource management
    >> architecture that should be able to handle cpusets needs, but despite my
    >> repeated (albeit not entirely successful) efforts to find documentation
    >> and read source and my pleadings with Matthew and earlier on this
    >> thread, I was never able to figure out what this meant, or find anything
    >> that could profitably integrate with cpusets.

    Rereading the earlier posts on the thread, I'd agree. There are some
    similarities in our interfaces but not enough to warrant a merger.


    -- Shailabh
    -
    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: 2005-03-22 14:10    [W:3.735 / U:0.028 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site