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

[Mandeep Singh Baines]

David Rientjes (rientjes@xxxxxxxxxx) wrote:
> On Thu, 11 Nov 2010, Mandeep Singh Baines wrote:
> 
> > > 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.
> > 
> 
> Well, it's a tangential point, but I'd personally prefer that my existing 
> tabs that I've decided to leave open are guaranteed to remain open 
> regardless of where I'm browsing next (they could hold valuable data that 
> I can't easily get back) and avoid having all of them sacrificed out from 
> under me for the newly opened tab.  I can always go back and close those 
> tabs for more memory if I know I don't need them anymore and then retry 
> the failed allocation.
> 
> > > 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.
> > 
> 
> We don't necessarily want arbitrary tasks to be able to decrease their 
> oom_score_adj back to 0 if a CAP_SYS_RESOURCE thread has elevated it, 
> that's part of the reason for the restriction (in addition to decreasing 
> your own oom_score_adj all the way to OOM_SCORE_ADJ_MIN).
> 
> Would it suffice to allow a task to decrease its oom_score_adj back to the 
> highest value that a CAP_SYS_RESOURCE thread set it or its inherited value 
> at fork?  Assuming the thread that has forked it has oom_score_adj of 0, 
> each tab could decrease it back from 0 upon activation unless a 
> CAP_SYS_RESOURCE thread elevated it to something higher.
> 
> To do this, we'd need to save the highest oom_score_adj set by a 
> CAP_SYS_RESOURCE in struct signal_struct.

Sounds good to me. I'll start working on this patch.

Thanks,
Mandeep
--
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/