int sysctl_optmem_max __read_mostly = sizeof(unsigned long)*(2*UIO_MAXIOV+512);

sizeof(unsigned long) is going to be different on ARM32 vs. other 64-bit arches, hence the difference. This has been the setting for a very long time, is there a reason changing it via sysctl is not an option?

(In reply to Laura Abbott from comment #1)
> int sysctl_optmem_max __read_mostly = sizeof(unsigned
> long)*(2*UIO_MAXIOV+512);
> 
> sizeof(unsigned long) is going to be different on ARM32 vs. other 64-bit
> arches, hence the difference.

I just checked and found `unsigned long` to be 32 bits on %{arm}, only.  All other arches (even %{ix86}) have it set to 64 bits.

unsigned long long seems to be at least 64-bit on all arches.


> This has been the setting for a very long
> time, is there a reason changing it via sysctl is not an option?

Well, yes…  One cannot change it using sysctl (or using other ways) without being root (and thus isn't an option for Koji builds).

The preset can be changed to be the same on all arches (based on changing that in systemd) by adding `net.core.optmem_max = 20480` to `/usr/lib/sysctl.d/50-default.conf`, tho.

Any ideas towards that?

Changing component to `systemd` since the implementation could be done there, without changing any defaults in kernel code.

Technically, changing it in systemd is easy. But in the long run, it seems like the wrong solution. If the current default is clearly useless, why not change it properly in the kernel and make the kernel behave properly out of the box? Please provide rationale why systemd should override the defaults provided by another package in this case.

(In reply to Zbigniew Jędrzejewski-Szmek from comment #4)
> Technically, changing it in systemd is easy. But in the long run, it seems
> like the wrong solution. If the current default is clearly useless, why not
> change it properly in the kernel and make the kernel behave properly out of
> the box? Please provide rationale why systemd should override the defaults
> provided by another package in this case.


My thought was:  We could override the default in systemd as a intermediate solution until there is a proper solution found to set it to a sane and consistent default in the kernel codebase.

The other option would be to carry a downstream patch to the kernel, which seems to be a much bigger effort than carrying a downstream patch on systemd…

Created attachment 1381615 [details]
Temporary patch for systemd

This patch adds the needed setting to systemd's sysctl defaults.  It applies on recent master of dist-git.

If this is acceptable as a temporary solution (until the default is fixed in kernel), please backport this to fc26 and fc27.

Thanks. But I really would prefer for this to be temporary. Do the kernel folks commit to trying to change this upstream in the kernel?

Created attachment 1381676 [details]
Patch for the kernel maintainers to be upstreamed in mainline kernel

This patches makes sure optmem_max limit is at least 20480 on any recent architecture; it might be bigger on future architectures.

(In reply to Zbigniew Jędrzejewski-Szmek from comment #7)
> Thanks. But I really would prefer for this to be temporary. Do the kernel
> folks commit to trying to change this upstream in the kernel?

If you do not disagree, I'll push my patch to systemd (and backport it to fc26+), trigger a build and push the updates.

I do disagree. I'm still waiting for an answer to the question in comment #c7.

To temporarily work around this problem, I've filed a ticket with fedora-infra [1] and added a reasonable sysctl preset for `net.core.optmem_max` in the libkcapi package.

To fix this in the long run, I've submitted a patch [2] for review to the Linux Kernel.


[1]  https://pagure.io/fedora-infrastructure/issue/6636
[2]  https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1587867.html