[torquedev] [PATCH] Change pbs_mom to set RLIMIT_AS instead of
RLIMIT_DATA for mem/pmem limits.
David.Singleton at anu.edu.au
Sat Jan 10 13:41:04 MST 2009
I have to agree with Ake:
* mem/pmem is for limiting RSS/physical memory use
* vmem/pvmem is for limiting virtual memory/address ranges
A job that mallocs/mmaps squigabytes of address space but never
accesses it should not suddenly be clobbered by mem/pmem
resource limits, only by vmem/pvmem limits.
pvmem seems like the obvious limit to use RLIMIT_AS.
Chris Samuel wrote:
> Hi folks,
> Responses will be sporadic for a while as we're still chasing
> annoyingly random hardware issues.. :-(
> ----- "Åke Sandgren" <ake.sandgren at hpc2n.umu.se> wrote:
>> I think this is a bad idea.
>> vmem and pvmem can be mapped to RLIMIT_AS but mem and pmem can't.
> If you want glibc to do what it used to then they are necessary.
>> If you set RLIMIT_AS for (p)mem then there is no way to use (p)vmem
>> any longer.
> I don't think that's true, pbs_mom already tests to ensure
> that (p)vmem > (p)mem and fixes it if it is not.
>> pmem is the memory usage, pvmem is the virtual memory usage.
> That's what Torque thinks, but..
>> RLIMIT_AS is virtual memory limit.
> ..this is no longer the case with the way that glibc has
> changed how it allocates memory, and like it or not RLIMIT_AS
> now does what RLIMIT_DATA used to to! :-(
Technically, glibc only ever allocates "virtual memory" in the
sense that it only adds or changes vma (virtual memory area) maps.
So any changes in glibc behaviour are related to virtual memory limits
Physical memory (pages) are allocated during page faults by the
kernel when a process tries to access virtual addresses with no
physical page backing. glibc has no hand in this.
More information about the torquedev