Re: [PATCH 1/1] mm, oom_adj: don't loop through tasks in __set_oom_adj when not necessary

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, Aug 20, 2020 at 10:48:43PM +0900, Tetsuo Handa wrote:
> On 2020/08/20 22:34, Christian Brauner wrote:
> > On Thu, Aug 20, 2020 at 03:26:31PM +0200, Michal Hocko wrote:
> >> If you can handle vfork by other means then I am all for it. There were
> >> no patches in that regard proposed yet. Maybe it will turn out simpler
> >> then the heavy lifting we have to do in the oom specific code.
> > 
> > Eric's not wrong. I fiddled with this too this morning but since
> > oom_score_adj is fiddled with in a bunch of places this seemed way more
> > code churn then what's proposed here.
> 
> I prefer simply reverting commit 44a70adec910d692 ("mm, oom_adj: make sure
> processes sharing mm have same view of oom_score_adj").
> 
>   https://lore.kernel.org/patchwork/patch/1037208/

I guess this is a can of worms but just or the sake of getting more
background: the question seems to be whether the oom adj score is a
property of the task/thread-group or a property of the mm. I always
thought the oom score is a property of the task/thread-group and not the
mm which is also why it lives in struct signal_struct and not in struct
mm_struct. But

44a70adec910 ("mm, oom_adj: make sure processes sharing mm have same view of oom_score_adj")

reads like it is supposed to be a property of the mm or at least the
change makes it so.

Christian



[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [Samba]     [Device Mapper]     [CEPH Development]

  Powered by Linux