Messages in this thread | | | Subject | Re: DOS by unprivileged user | From | Mike Galbraith <> | Date | Mon, 23 Apr 2018 10:04:36 +0200 |
| |
On Sun, 2018-04-22 at 21:37 +0200, Ferry Toth wrote: > > Yes your memory hog scenario thoroughly wrecks the user experience, but > > the process scheduler in not the source of that wreckage, it's a memory > > management issue. With no constraints in place, anybody can just keep > > on allocating until the entire system starts grinding itself to dust. > > > > -Mike > > That is exactly the issue I think. It is not just a user experience, > they is no distinction between crashing the kernel and grinding it to > dust. The effect we have is: any user on a multi user system can > crash the system. > > Memory management / constraints can't solve the problem either: it > might be intentional to alloc such amounts of memory.
Constraints definitely can solve this particular problem instance. Plain old ulimit can stop the memory hog (wish) dead in its tracks, or you can use memory cgroup controller to constrain it in a more friendly manner. I started gitk in a 4G constrained cgroup, which redirected its greedy fingers to the swap bin for the remainder of its needs.
But yes, there is currently no wonderful one size fits all fully automatic solution to running low on memory that doesn't involve running to the store.
> I think memory allocation and io waits can't be decoupled from > scheduling as they are now.
The scheduler is not decoupled from either, it is intimately involved in both. However, none of the decision making smarts for either reside in the scheduler, nor should they.
-Mike
| |