Since we are reading these in as unsigned longs (which in most systems is a uint64_t) it does make sense to change them to uint64_t.

On 03/03/14 09:36, Danny Auble wrote:
vsize_max is in KB (rss is as well), so I think 12TB should fit into a uint32_t.

The more concerning issue would be how we read that info from proc.

Could you send me a line from  /proc/<pid>/stat of a process that is using all 12TB of memory (or more than 4TB of memory anyway).

Danny

On 03/03/14 08:39, bugs@schedmd.com wrote:
Site -Other-
Bug ID 619
Summary Increase vsize_max to uint64_6
Product SLURM
Version 2.6.6
Hardware Linux
OS Linux
Status UNCONFIRMED
Severity 5 - Enhancement
Priority ---
Component Accounting
Assignee david@schedmd.com
Reporter plazonic@princeton.edu
CC da@schedmd.com, david@schedmd.com, jette@schedmd.com 

Currently vsize_max and similar values are tracked with a 32bit uint (in
kilobytes):

slurm-2.6.6-2/slurm/slurmdb.h:  uint32_t vsize_max;

which makes the max value that it can track to be 4TBs.  That's too small for
our UV (it has 12TBs) and it is easy to see that it will be a limiting factor
for many more machines in future.  Can you please consider changing vsize_max
and other such values to uint64_t?

Thanks
You are receiving this mail because: