How can I enable cgroups2 on my laptop?
On Fri, Oct 19, 2018, 17:27 Lennart Poettering <mzerq...@0pointer.de> wrote:
> On Fr, 19.10.18 09:12, Florian Weimer (fwei...@redhat.com) 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@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> 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@lists.fedoraproject.org
>
_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org
