3 ms·

Basically, the question is this: is it possible to develop a process manager that would do the job of oomkiller that has as high code quality as the Linux kerne

Basically, the question is this: is it possible to develop a process manager that would do the job of oomkiller that has as high code quality as the Linux kernel. I am guessing the answer is yes I'm not trying to put the kernel devs on a pedestal or anything, but how can you compare a tool that's been tested in a myriad of use cases in literally everything from microcontrollers to clusters and big iron to something that's much less mature and probably won't see a tenth of the use cases? My bet is that you'll see more and more problems as people try to reinvent the wheel with their own "not-oom-killers", and blame it on the Linux kernel (ie, 99% of problems will be case 4, not nearly the same frequency). In that respect this article is incredibly informative as it will hopefully point people to check out their own code first. And the beauty is, if they do come up with a better oom-killer, they can always contribute a patch to the kernel.

IgorPartola 12y ago
Well, that's why I said that in the long term this might be solved. There is nothing as good right now, but in principle it could exist. Secondly, I doubt that a process manager with support for cgroups would need to run on microcontrollers. At least up to this point, I have not seen many microcontrollers running Linux containers. Lastly, a hybrid solution could be good: process manager identifies what processes to kill and in what order, oomkiller does the killing.
- npsimons 12y ago
  My point about running on microcontrollers is that the Linux kernel (and oom-killer in particular) has been tested on more use cases than most developers usually consider. This testing/usage has revealed mistaken design decisions and bugs. Very few process managers created from scratch will have been tested on nearly as many use cases and will naturally not be as robust. I do agree with you about the hybrid solution, with a twist: since the oom-killer has been so widely tested, I would think that if someone needed different performance parameters, it might behoove them to start with the oom-killer and tune it, modifying the source if necessary, instead of re-inventing the wheel from scratch.

IgorPartola 12y ago

Well, that's why I said that in the long term this might be solved. There is nothing as good right now, but in principle it could exist. Secondly, I doubt that a process manager with support for cgroups would need to run on microcontrollers. At least up to this point, I have not seen many microcontrollers running Linux containers. Lastly, a hybrid solution could be good: process manager identifies what processes to kill and in what order, oomkiller does the killing.

npsimons 12y ago
My point about running on microcontrollers is that the Linux kernel (and oom-killer in particular) has been tested on more use cases than most developers usually consider. This testing/usage has revealed mistaken design decisions and bugs. Very few process managers created from scratch will have been tested on nearly as many use cases and will naturally not be as robust. I do agree with you about the hybrid solution, with a twist: since the oom-killer has been so widely tested, I would think that if someone needed different performance parameters, it might behoove them to start with the oom-killer and tune it, modifying the source if necessary, instead of re-inventing the wheel from scratch.