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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
