Re: [PATCH 1/5] cpuset memory spread basic implementation

[Christoph Lameter <clameter@engr.sgi.com>]

On Mon, 6 Feb 2006, Ingo Molnar wrote:

> the grep faults in the pagecache, and depending on which job is active 
> first, the placement of the pages will either be spread out or local, 
> depending on the timing of those jobs. How do you expect this to behave 
> deterministically?

It behaves using node local allocation as expected. The determinism is 
only broken when the user sets up a cpuset. This is an unusual activity 
by the sysadmin and he will be fully aware of what is going on.

> cases i suspect what matters are project-specific data files - which 
> will be allocated deterministically because they are mostly private to 
> the cpuset. But e.g. /usr files want to be local in most cases, even for 
> a 'spread out' cpuset. Why would you want to allocate them globally?

We allocate nothing globally.

> 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.

> so if two projects want to use the same file in two different ways at 
> the same time then there is no solution either under the VFS-based or 
> under the cpuset-based approach - but at least the VFS-based method is 
> fully predictable, and wont depend on which science department starts 
> its simulation job first ...

It will just reduce performance by ~20% for selected files. Surely nobody 
will notice ;-)
-
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/