Messages in this thread | | | Date | Mon, 6 Feb 2006 14:10:07 -0800 (PST) | From | Christoph Lameter <> | Subject | Re: [PATCH 1/5] cpuset memory spread basic implementation |
| |
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/
| |