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

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

On Mon, 6 Feb 2006, Ingo Molnar wrote:

> it's a feature, not a weird effect! Under the VFS-driven scheme, if two 
> projects (one 'local' and one 'global') can access the same (presumably 
> big) file, then the sysadmin has to make up his mind and determine which 
> policy to use for that file. The file will either be local, or global - 
> consistently.

But that local or global allocation policy depends on what task is 
accessing the data at what time. A simple grep should not result in 
interleaving. A big application accessing the same data from multiple 
processes should have interleaving for shared data. Both may not be active 
at the same time.
 
> with the per-cpuset policy approach on the other hand it would be 
> non-deterministic which policy the file gets allocated under: whichever 
> cpuset first manages to touch that file. That is what i'd call a weird 
> and undesirable effect. This weirdness comes from the conceptual hickup 
> of attaching the object-allocation policy to the workload, not to the 
> file objects of the workload - hence conflicts can arise if two 
> workloads share file objects.

Well these weird effects are then at least expected since there was a 
cpuset set up for applications to activate this effect and the 
processes running in that cpuset will behave in the weird way we want.

The mountpoint option means that reading the contents of a file in some 
filesystems is slower than in others because some files spread their pages 
all over the system while others are node local. Again if the process is 
single threaded the node local is always the right approach. These single 
threaded processes will no longer be able to run with full pagecache 
speed. Memory will be used in other nodes that may have been reserved for 
other purposes by the user.

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