Dan Čermák <dan.cermak@xxxxxxxxxxxxxxxxxxx> writes: > Robbie Harwood <rharwood@xxxxxxxxxx> writes: > >> Ben Cotton <bcotton@xxxxxxxxxx> writes: >> >>> For swap based actions, systemd-oomd will monitor the system-wide swap >>> space and act when available swap falls below the configured >>> threshold, starting with the cgroups with the highest swap usage to >>> the least. Keeping some amount of swap (if enabled) available will >>> prevent the kernel OOM killer from killing processes unpredictably and >>> spending an unbounded amount of time afterwards. >> >> -1 from me. If the kernel behavior is a problem, fix it - don't kludge >> around it in userspace. > > That is unlikely to happen. As far as I know, the kernel devs see the > kernel oom killer as a kernel self protection measure and want it to > fire as the last resort (and they are quite hesitant to touch > userspace). I believe you are assuming the consequent when you suggest that kernel developers should be somehow fixing this in userspace. To back up: the described problem is the manifestation of an interaction between swap and the OOM condition. The OOM killer is a popularly-understood piece of what goes on in the system during OOM, but it's not like the rest of the kernel can be ignored. (I would argue that part of the reason it's well understood is their insistence that it remain simple, but that's getting off into the weeds.) So, several control points here: - OOM killer behavior. I think we're in agreement that this isn't the thing that needs changed. - Enabling swap. Swap is really slow (by virtue of not being RAM...) and we don't seem willing to acknowledge that. If we want the system to be snappy and responsive... we shouldn't be swapping. - Swap aggressiveness. Suggested by above, people want swap anyway. (Sometimes it's for hibernation (not supported, but that stops no one), sometimes it's for... historical reasons? Underprovisioning?) This could be tuned to the use cases we actually want. - Education. Get people to a point where admins don't deploy swap on systems that aren't going to hibernate. I'll readily admit this one might be hardest. And even possibly the (conceptually) simplest solution of all: - Swap usage monitoring as described for oomd... but in the kernel. This saves you on all the overhead of running in userspace, if nothing else. But what really bothers me here is that, to my knowledge, no one has tried to actually make any of these happen in the kernel. There's a vague perception of what "the kernel devs" want, as if they're some other, but... has anyone asked? If so, we should be able to quote what the response was, and a good design proposal should include it as an explanation of why that route wasn't taken. Thanks, --Robbie
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
