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

[Simon Derr]

On Fri, 3 Feb 2006, Paul Jackson wrote:

> This policy can provide substantial improvements for jobs that
> need to place thread local data on the corresponding node, but
> that need to access large file system data sets that need to
> be spread across the several nodes in the jobs cpuset in order
> to fit.  Without this patch, especially for jobs that might
> have one thread reading in the data set, the memory allocation
> across the nodes in the jobs cpuset can become very uneven.
> 

Oh, that's good news for me.
I was receiving more and more complains about this kind of issues.
I feel this is really a good answer to the typical "page cache ate all my 
node memory" case, which is *really* a pain for many HPC apps that access 
large files.

Thanks Paul.

AKPM wrote:

> IOW: this patch seems to be a highly specific bandaid which is repairing 
> an ill-advised problem of our own making, does it not?

I'm not sure about the 'ill-advised' part. All our efforts to let the 
kernel do the Right Thing by himself on all situations should not prevent 
us from remembering that Linux is not a time machine, and that sometimes, 
it is just a lot easier and probably better to give the kernel a few hints 
about what it should do.

And even if this can seem 'specific', this kind of workload is NOT rare, 
at least in HPC.

	Simon.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/