linux-kernel - Re: [PATCH RESEND v2 2/2] mm: delete unused MMF_OOM

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 29 Aug 2022 12:40:04 +0200
From:   Michal Hocko <mhocko@...e.com>
To:     Yu Zhao <yuzhao@...gle.com>
Cc:     Andrew Morton <akpm@...ux-foundation.org>,
        Suren Baghdasaryan <surenb@...gle.com>,
        David Rientjes <rientjes@...gle.com>,
        Matthew Wilcox <willy@...radead.org>,
        Johannes Weiner <hannes@...xchg.org>,
        Roman Gushchin <guro@...com>, Minchan Kim <minchan@...nel.org>,
        "Kirill A . Shutemov" <kirill@...temov.name>,
        Andrea Arcangeli <aarcange@...hat.com>, brauner@...nel.org,
        Christoph Hellwig <hch@...radead.org>, oleg@...hat.com,
        David Hildenbrand <david@...hat.com>,
        Jann Horn <jannh@...gle.com>,
        Shakeel Butt <shakeelb@...gle.com>,
        Peter Xu <peterx@...hat.com>,
        John Hubbard <jhubbard@...dia.com>, shuah@...nel.org,
        linux-kernel <linux-kernel@...r.kernel.org>,
        Linux-MM <linux-mm@...ck.org>, linux-kselftest@...r.kernel.org,
        kernel-team@...roid.com
Subject: Re: [PATCH RESEND v2 2/2] mm: delete unused MMF_OOM_VICTIM flag

On Sun 28-08-22 13:50:09, Yu Zhao wrote:
> On Tue, Aug 23, 2022 at 2:36 AM Michal Hocko <mhocko@...e.com> wrote:
[...]
> > You cannot really make any
> > assumptions about oom_reaper and how quickly it is going to free the
> > memory.
> 
> Agreed. But here we are talking about heuristics, not dependencies on
> certain behaviors. Assume we are playing a guessing game: there are
> multiple mm_structs available for reclaim, would the oom-killed ones
> be more profitable on average? I'd say no, because I assume it's more
> likely than unlikely that the oom reaper is doing/to do its work. Note
> that the assumption is about likelihood, hence arguably valid.

Well, my main counter argument would be that we do not really want to
carve last resort mechanism (which the oom reaper is) into any heuristic
because any future changes into that mechanism will be much harder to
justify and change. There is a cost of the maintenance that should be
considered. While you might be right that this change would be
beneficial, there is no actual proof of that. Historically we've had
several examples of such a behavior which was really hard to change
later on because the effect would be really hard to evaluate.

-- 
Michal Hocko
SUSE Labs