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.075 / U:0.616 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site