Chris Murphy <lists@xxxxxxxxxxxxxxxxx> writes: > On Mon, Aug 12, 2019 at 5:47 PM Emery Berger <emery.berger@xxxxxxxxx> wrote: >> >> For what it's worth, my research group attacked basically exactly this problem some time ago. We built a modified Linux kernel that we called Redline that was utterly resilient to fork bombs, malloc bombs, and so on. No process could take down the system, much less unprivileged ones. I think some of the ideas we described back then would be worth adopting / adapting today (the code is of course hopelessly out of date: we published our paper on this at OSDI 2008). > > I'm unable to find a concurring or dissenting opinions on this. What > kind of peer review has it received? Was it ever raised with upstream > kernel developers? What were there responses? I have only read parts of the Redline paper so I do not know if it was ever tried to submit this upstream. Judging from the Redline webpage (https://emeryberger.com/research/redline/), it appears to only ever been implemented on i386 and nowhere else (albeit that shouldn't be hard to fix). Furthermore it does not support NUMA, which might be a bigger blocker. My guess is that Redline might clash with the general idea how processes should be scheduled of upstream Linux. Redline solves the problem of keeping interactive applications interactive even under severe memory pressure by changing the way they are scheduled, allocated memory and how much data they are allowed to read from disks. If an application is classified as interactive (in contrast to best-effort tasks, which corresponds to a process in the current Linux kernel), then it will get a requested amount of CPU time each x ms (e.g. to be able to run at 25 fps). Something comparable is done with memory and disk usage. This is a pretty nice approach in my opinion but it has certain downsides: - scheduling gets more complicated - you need additional system calls to tell the kernel which processes are interactive (otherwise they are treated the "old" way and you gain nothing) - you need a userspace component that has a database of interactive tasks (with a small set of configs, e.g. how often does your process need a chunk of the CPU time) It could be that the kernel community would perceive that as a blocker and would instead prefer a different and more generic solution (this is just my personal guess). It could also very well be that no one had time to actually upstream this, as it was an academic project (no offense intended, I've been in academia myself and know how things go). Unfortunately, Redline was developed more than a decade ago, so upstreaming it nowadays is probably equivalent to a full rewrite, given the kernel's development pace. Cheers, Dan
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
