On Thu 20-08-20 16:00:54, Christian Brauner wrote:
> 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
I would tend to agree that from the userspace POV it is nice to look at
oom tuning per process but fundamentaly the oom killer operates on the
address space much more than other resources bound to a process because
it is usually the address space hogging the largest portion of the
memory footprint. This is the reason why the oom killer has been
evaluating tasks based on that aspect rather than other potential memory
consumers bound to a task. Mostly due to lack of means to evaluate
those.
> 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.
Yes, based on the current and historical behavior of the oom killer.
--
Michal Hocko
SUSE Labs
