Re: raise fileno limit to make Steam Proton / Wine+esync work well in Fedora

[Zbigniew Jędrzejewski-Szmek]

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
> <mzerqung(a)0pointer.de&gt; wrote:
>  
>  > On Fr, 19.10.18 09:12, Florian Weimer (fweimer(a)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(a)lists.fedoraproject.org
>  > To unsubscribe send an email to devel-leave(a)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/[e-mail]
>  > 
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)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/[e-mail]