On Fr, 05.10.18 12:28, Nicholas Miell (nmiell(a)gmail.com) wrote:
>> This is not quite the 1M you appear to ask for though… I
>> mostly because I wanted to stay lower than the kernel built-in max
>> (which is 1M, i.e. /proc/sys/fs/nr_open), and needed to pick
>> something. Do you have any particular reason to prefer 1M over 256K? I
>> am completely open to suggestions there...
> The upstream esync branch requests setting the hard limit to 1M.
> I haven't torn apart the project to see if 1M is really necessary so a
> different limit may be up for discussion.
esync uses eventfd to reduce IPC to wineserver when emulating Windows
kernel objects, the exact number of eventfds needed depends entirely on
the behavior of the Windows application you are running.
So, any idea why they picked 1M? Are there typical apps that require
really that many?
I mean, it could be two things:
1) yes, they ran into real-life apps that require 500K fds and hence
set the limit to 1M since they can't set it any higher anyway, and
it's far away from (i.e. double of) 500K.
2) no, they didn't run into real-life apps like this, but didn't want
to figure out what a good limit is, hence they set it to the
kernel's built-in maximum of 1M.
If it's #1 then I figure we should bump the systemd upstream to 1M
too. If it's #2, then I figure we can start with 256K as my PR
currently does, for now.
Lennart Poettering, Red Hat