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 [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]
