Arch Linux

This should be set via a file in /usr/lib/sysctl.d; we just need a package to put it in.

Ubuntu uses a default of 524288 (2¹⁹), which should be fine.

+1 for me, this will make pycharm and idea shut up about it being too low as well.

Once again though, I'm not sure why the user cannot do this themselves?

Arch generally shouldn't deviate from upstream (I rely on this de facto standard) and since this is not a compile-time issue, I fail to see why a respective user who needs such a thing cannot simply set this themselves.

Issues like flow being awful is an issue for their upstream, not for downstream to workaround.

It's a common stumbling block that might affect who knows how many applications which were only tested on the largest distributions. I'd rather avoid having our users run into this when the only drawback is a potential increase in kernel memory usage. Unlike the upstream kernel we're not targeting embedded devices as well.

I fully appreciate the sentiment. Providing a more user-friendly environment is why distributions like Ubuntu and SolusOS exists so I can completely sympathise with this kind of reasoning, but why should this apply to Arch Linux?

I spend a lot of time testing software, making bug reports, providing fixes where I can, and more. I use Arch Linux *specifically* because it is not Ubuntu or SolusOS, because it largely retains upstream purity. This is necessary when trying to reproduce and verify issues and if this bedrock is slowly erroded to provide a better set of defaults for users, then why not just use a distribution dedicated to excelling in that aspect?

All Arch Linux will become is a worse version of Fedora with none of the financial backing or critical mass.

PS: You have to understand, this is a principled position. It doesn't really have too much to do with the issue at hand except for the consideration between compile-time and runtime choice. Everything that has a runtime component need not be changed as users can do this themselves. Compile-time is more difficult.

i like this change but want to add a little more info:

in a quick test with inotifywatch, watching 2^19 dirs used ~160M total / ~56M kernel (/proc/meminfo: Slab) for me. so assuming 512M RAM, Arch's stated minimum requirement, that would be ~11% for unswappable kernel memory a user could "steal".

i did a little more digging and to me it seems that the (ridiculously low) upstream default is simply a case of legacy cruft, set once and forgotten.

taking a look at inotify and epoll in the kernel source:

inotify:
- max_user_instances defaults to 128
- max_user_watches defaults to 8192
- both are static limits
- both were introduced 13 years ago in 2005 with the initial merge of inotify [1]
- both were never altered since, still the same in 4.18 [2]

epoll:
- in 2008 epoll also got max_user_instances (128) and max_user_watches with the commit explicitly mentioning that this was to prevent users from requesting too much kernel memory [3]
- max_user_instances got removed soon after because max_user_watches was considered sufficient on its own [4]
- max_user_watches was introduced with a _dynamic_ default depending on system RAM, currently allowing at most 4% of RAM for the kernel memory structures per user [5,6]


makes me wonder: could the epoll dynamic default approach be used for inotify as well, upstream?



[1] https://github.com/torvalds/linux/commit/0eeca28300df110bd6ed54b31193c83b87921443#diff-6812e7d63790ab6b79eead5cc97dce72R983
[2] https://github.com/torvalds/linux/blob/v4.18/fs/notify/inotify/inotify_user.c#L815
[3] https://github.com/torvalds/linux/commit/7ef9964e6d1b911b78709f144000aacadd0ebc21
[4] https://github.com/torvalds/linux/commit/9df04e1f25effde823a600e755b51475d438f56b
[5] https://github.com/torvalds/linux/blob/v4.18/Documentation/sysctl/fs.txt#L328
[6] https://github.com/torvalds/linux/blob/v4.18/fs/eventpoll.c#L2297

Sounds great. I'm sure the kernel would accept a patch. (I'd be willing to have it in ZEN earlier).