lkml.org 
[lkml]   [2006]   [Feb]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH 1/5] cpuset memory spread basic implementation

    * Christoph Lameter <clameter@engr.sgi.com> wrote:

    > > but a single object cannot be allocated both locally and globally!
    > > (well, it could be, for read-mostly workloads, but lets ignore that
    > > possibility) So instead of letting chance determine it, it is the most
    > > natural thing to let the object (or its container) determine which
    > > strategy to use - not the workload. This avoids the ambiguity at its
    > > core.
    >
    > We want cpusets to make a round robin allocation within the memory
    > assigned to the cpuset. There is no global allocation that I am aware
    > of.

    i think we might be talking about separate things, so lets go one step
    back.

    firstly, i think what you call roundrobin is what i call 'global'.
    [roundrobin allocation is what is best for a cache that is accessed in a
    'global' way - as opposed to cached data that is accessed in a 'local'
    way.]

    secondly, i'm not sure i understood it correctly why you want to have
    all (mostly filesystem related) allocations within selected cpusets go
    in a roundrobin way. My understanding so far was that you wanted this
    because the workload attached to that cpuset was using the filesystem
    objects in a 'global' way: i.e. from many different nodes, with no
    particular locality of reference. Am i mistaken about this?

    Ingo
    -
    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: 2006-02-07 00:33    [W:0.022 / U:11.300 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site