Messages in this thread | | | Date | Mon, 6 Feb 2006 10:18:02 +0100 (CET) | From | Simon Derr <> | Subject | Re: [PATCH 1/5] cpuset memory spread basic implementation |
| |
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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |