On Wed, 30 May 2012, Rayson Ho wrote:
...
I'm provisionally using the name h_mem / s_mem to control cgroup memory
enforcement, but am willing to be argued into changing this.
Can you define a name for the "memsw.limit_in_bytes" cgroup memory
controller limit??
s_mem / h_mem? [best name, but clashes a little with "mem" usage?]
s_memsw / h_memsw? [too Linux-specific?]
s_osmem / h_osmem? [too ugly?]
Last week, I asked Ron Chen to work with the kernel mailing list guys
to see if we can get the behavior that you & others are requesting...
but I guess even if the Linux kernel were to add this functionality,
it would still take ages for distributions to switch to a new kernel.
...
Hi Rayson,
I'm not sure I understand and I wonder if we're talking at cross-purposes.
All the functionality required for what I want is already right there in
the Linux memory cgroup controller today (or at least it is on RHEL6):
* memory.limit_in_bytes (for rss control)
* memory.memsw.limit_in_bytes (for rss+swap control)
* memory.memsw.failcnt (check if rss+swap has been exceeded)
Please correct me if I've misunderstood but, from previous emails, I
thought you were already using these in your new cgroup code: h_vmem would
now set both memory.memsw.limit_in_bytes and setrlimit's RLIMIT_AS.
The problem I have with this, is that some jobs benefit from being able to
specify these two quantities independently.
As I don't want to go down one route with my patchset while the rest of
the community goes down another, my question is:
Do you support the idea of introducing a new gridengine attribute to
control memory.memsw.limit_in_bytes and leave h_vmem to just deal with
setrlimit's RLIMIT_AS, as previously?
Best wishes,
Mark
--
-----------------------------------------------------------------
Mark Dixon Email : [email protected]
HPC/Grid Systems Support Tel (int): 35429
Information Systems Services Tel (ext): +44(0)113 343 5429
University of Leeds, LS2 9JT, UK
-----------------------------------------------------------------
_______________________________________________
users mailing list
[email protected]
https://gridengine.org/mailman/listinfo/users
