Messages in this thread | | | Date | Thu, 11 Nov 2010 14:25:10 -0800 | From | Mandeep Singh Baines <> | Subject | Re: [PATCH] oom: create a resource limit for oom_adj |
| |
David Rientjes (rientjes@google.com) wrote: > 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. >
If you're watching a movie, video chatting, playing a game, etc. What would you rather have killed: the current tab you are interacting with or some tab you opened a while back and are no longer interacting with.
> 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? >
Exactly.
> 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
Security. We want to use the least-privilege possible. We really want to avoid giving special privileges to the browser. You shouldn't need administrative privileges to run the browser. We'd like for oom_score_adj to work the same as nice. An unprivileged user can nice up and down as long as the new setting is within the administratively configured resource limit: ulimit -e.
> 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)?
| |