Re: [PATCH] oom: create a resource limit for oom_adj

From: David Rientjes
Date: Thu Nov 11 2010 - 15:57:47 EST


On Thu, 11 Nov 2010, Mandeep Singh Baines wrote:

> > What is the anticipated use case for this? We know that you want to lower
> > oom_adj without CAP_SYS_RESOURCE, but what's the expected behavior when an
> > app moves from foreground to background? I assume it's something like
>
> The focus here is the web browser's tabs. In our case, each is a process. If
> OOM is going to kill a process, you'd rather it kill the tab you looked at
> hours ago instead of the one you're looking at now. So you'd like to have a
> policy where the LRU tab gets killed first. We'd like to use oom_score_adj
> as the mechanism to implement an LRU policy like this.
>

Hmm, at first glance that seems potentially dangerous if the current tab
generates a burt of memory allocations and it ends up killing all other
tabs before finally targeting the culprit whereas currently the heuristic
should do a good job of finding this problematic tab and killing it
instantly.

Perhaps that can't happen and it probably doesn't even matter:
oom_score_adj allows users to determine which process to kill regardless
of the underlying reason.

> > What do you anticipate will be writing to oom_score_adj with this patch,
> > the app itself?
>
> A process in the browser session will do the adusting. We'd rather not give
> it CAP_SYS_RESOURCE. It should only be allowed to change oom_score_adj up
> and down within the bounds set by the administrator. Analagous to renice()
> which we also do using a similar policy.
>

So as more and more tabs get used, the least recently used tab gets its
oom_score_adj raised higher and higher until it is reused itself and then
it gets reset back to 0 for the current tab?

Is there a reason you don't want to give the underlying browser session
process CAP_SYS_RESOURCE? Will it not be enforcing resource limits to
ensure tabs don't deplete all memory when certain sites are opened? Are
you concerned that it may deplete all memory itself (for which case you
could raise its own oom_score_adj, which is a proportion of available
memory so you can define where that point of depletiong is)?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/