On 20/08/2026 09:54, Bruno Haible via Gnulib discussion list wrote:
Collin Funk wrote:
Given that physmem doesn't account for cgroups though, 'sort' may
allocate more than allowed by a cgroup, leading to a process being
killed.
...
I think that it would be nice to account for cgroup memory limits here
Sounds fine for physmem_available and physmem_claimable.
For physmem_total, I'm not sure. It is defined as "the total amount of
physical memory". So, either
- leave physmem_total as it is, or
- invent a new function physmem_in_container,
- or add a 'bool in_container' parameter to physmem_total.
I'm not sure I agree with physmem_total ignoring cgroups.
If one does `sort --buffer-size=50%` you would want it
based on the current static defined limit, whether that's physical memory,
or what has been configured as the max possible.
Looking at the comment for physmem_total in lib/physmem.h it's described as:
"more or less a hard limit for the working set"
which to me should reflect the cgroup limit.
If we did also provided a phsysmem_max and adjusted sort(1) to use that,
then how useful would physmem_total be. I.e. what would that ever be used for?
Re syscall overhead, it's unfortunate, but I don't see a way
around that at present. I would hope that at some stage
the kernel will provide an interface to a single calculated value
for these limits. I do note that sort(1) uses both nproc() and physmem_total(),
which suggests a shared or cached interface may be useful, but that
can come at a later stage. Currrent cgroup accesses can be seen with:
$ strace -o /dev/stdout sort /dev/null | grep cgroup
As for implementing the support, it's essentially the same implementation
as for cpu.max, except that we don't have to worry about scheduler.
So the cgroup walking logic could be refactored to a shared module.
I was going to do that at some stage,
but am happy for others to implement if they've time.
cheers,
Padraig
