| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <6599ad830609201653g4f44a4frb308eaeb63f83d2a@mail.google.com> Date: Wed, 20 Sep 2006 16:53:30 -0700 From: "Paul Menage" <menage@...gle.com> To: "Paul Jackson" <pj@....com> Cc: alan@...rguk.ukuu.org.uk, clameter@....com, npiggin@...e.de, ckrm-tech@...ts.sourceforge.net, linux-kernel@...r.kernel.org, rohitseth@...gle.com, devel@...nvz.org Subject: Re: [ckrm-tech] [patch00/05]: Containers(V2)- Introduction On 9/20/06, Paul Jackson <pj@....com> wrote: > > The way you "associate" a file with a cpuset is to have some task in > that cpuset open that file and touch its pages -- where that task does > so before any other would be user of the file. An alternative would be a way of binding files (or directory hierarchies) to a particular set of memory nodes. Then you wouldn't need to pre-fault the data. Extended attributes might be one way of doing it. > > Such pre-touching of files is common occurrence on the HPC (High Perf > Comp.) apps that run on the big honkin NUMA iron where cpusets were > born. I'm guessing that someone hosting 5000 web servers would rather > not deal with that particular hastle. I'm looking at it from the perspective of job control systems that need to have a good idea what big datasets the jobs running under them are touching/sharing. Paul - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists