On Wed, Oct 24, 2018 at 08:45:32AM +0200, Igor Gnatenko wrote:
> How can I enable cgroups2 on my laptop?
Put systemd.unified-cgroup-hierarchy on the kernel command line.
Zbyszek
> 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
_______________________________________________
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
