On Fr, 19.10.18 09:12, Florian Weimer (fweimer@xxxxxxxxxx) wrote:
> >> (cross-posting to devel and desktop lists, ideally reply to both)
> >
> > Coincidentally, at All Systems Go! in Berlin last week I had some
> > discussions with kernel people about RLIMIT_NOFILE defaults. They
> > basically suggested that the memory and performance cost of large
> > numbers of fds on current kernels is cheap, and that we should bump
> > the hard limit in systemd for all userspace processes.
>
> Which kernel version is that? Is that a new patch? Or some older
> kernel?
>
> It's definitely not true for kernel 4.18, see the script I posted.
I inquired Tejun Heo about this all, this is what he replied:
<snip>
In cgroup1, socket buffers are handled by a separate memory
sub-controller. It's cumbersome to use, somewhat broken and doesn't
allow for comprehensive memory control. cgroup2, however, by default
accounts socket buffer as part of a given cgroup's memory consumption
correctly interacting with socket window management.
OOM killer too fails to take socket buffer into account and high
number of sockets can lead it to make ineffective decisions; however,
this failure mode isn't confined to high number of sockets at all -
fewer number of fat pipes, tmpfs, mount points or any other kernel
objects which can be pinned by processes can trigger this.
cgroup2 can track or control most of these usages and at least for us
switching to oomd for workload health management solves most of the
problems that we've encountered. In the longer term, the kernel OOM
killer can be improved to make better decisions too.
</snip>
("us" in the above is facebook btw.)
So, yeah, if we'd use cgroupv2 on Fedora, then everything would be
great (unfortunately the container messiness blocks that for now). But
as long as we don't, lifting the fd limit is not really making things
worse, given that there are tons of other easily exploitable ways to
acquire untracked memory...
Lennart
--
Lennart Poettering, Red Hat
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
