Date:	Thu, 11 Nov 2010 14:25:10 -0800
From:	Mandeep Singh Baines <msb@...omium.org>
To:	David Rientjes <rientjes@...gle.com>
Cc:	Mandeep Singh Baines <msb@...omium.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	KAMEZAWA Hiroyuki <kamezawa.hiroyu@...fujitsu.com>,
	KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>,
	Rik van Riel <riel@...hat.com>,
	Ying Han <yinghan@...gle.com>, linux-kernel@...r.kernel.org,
	gspencer@...omium.org, piman@...omium.org, wad@...omium.org,
	olofj@...omium.org
Subject: Re: [PATCH] oom: create a resource limit for oom_adj

David Rientjes (rientjes@...gle.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)?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists