lkml.org 
[lkml]   [2004]   [Oct]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [ckrm-tech] Re: [Lse-tech] [PATCH] cpusets - big numa cpu and memory placement
    --On Monday, October 04, 2004 08:53:27 -0700 Paul Jackson <pj@sgi.com> wrote:

    > Martin writes:
    >> OK, then your "exclusive" cpusets aren't really exclusive at all, since
    >> they have other stuff running in them.
    >
    > What's clear is that 'exclusive' is not a sufficient precondition for
    > whatever it is that CKRM needs to have sufficient control.
    >
    > Instead of trying to wrestle 'exclusive' into doing what you want, do me
    > a favor, if you would. Help me figure out what conditions CKRM _does_
    > need to operate within a cpuset, and we'll invent a new property that
    > satisfies those conditions.

    Oh, I'm not even there yet ... just thinking about what cpusets needs
    independantly to operate efficiently - I don't think cpus_allowed is efficient.

    Whatever we call it, the resource management system definitely needs the
    ability to isolate a set of resources (CPUs, RAM) totally dedicated to
    one class or group of processes. That's what I see as the main feature
    of cpusets right now, though there may be other things there as well that
    I've missed? At least that's the main feature I personally see a need for ;-)

    > See my earlier posts in the last hour for my efforts to figure out what
    > these conditions might be. I conjecture that it's something along the
    > lines of:
    >
    > Assuring each CKRM instance that it has control of some
    > subset of a system that's separate and non-overlapping,
    > with all Memory, CPU, Tasks, and Allowed masks of said
    > Tasks either wholly owned by that CKRM instance, or
    > entirely outside.

    Mmm. Looks like you're trying to do multiple CKRMs, one inside each cpuset,
    right? Not sure that's the way I'd go, but maybe it makes sense.

    The way I'm looking at it, which is probably wholly insufficient, if not
    downright wrong, we have multiple process groups, each of which gets some
    set of resources. Those resources may be dedicated to that class (a la
    cpusets) or not. One could view this as a set of resource groupings, and
    set of process groupings, where one or more process groupings is bound to
    a resource grouping.

    The resources are cpus & memory, mainly, in my mind (though I guess IO,
    etc fit too). The resource sets are more like cpusets, and the process
    groups a bit more like CKRM, except they seem to overlap (to me) when
    the sets in cpusets are non-exclusive, or when CKRM wants harder performance
    guarantees.

    Feel free to point out where I'm full of shit / missing the point ;-)

    M.

    -
    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:06    [W:2.411 / U:0.008 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site