[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.DEB.2.10.1712111507520.14765@chino.kir.corp.google.com>
Date: Mon, 11 Dec 2017 15:09:58 -0800 (PST)
From: David Rientjes <rientjes@...gle.com>
To: Paolo Bonzini <pbonzini@...hat.com>
cc: Andrew Morton <akpm@...ux-foundation.org>,
Michal Hocko <mhocko@...e.com>,
Andrea Arcangeli <aarcange@...hat.com>,
Benjamin Herrenschmidt <benh@...nel.crashing.org>,
Paul Mackerras <paulus@...ba.org>,
Oded Gabbay <oded.gabbay@...il.com>,
Alex Deucher <alexander.deucher@....com>,
Christian König <christian.koenig@....com>,
David Airlie <airlied@...ux.ie>,
Joerg Roedel <joro@...tes.org>,
Doug Ledford <dledford@...hat.com>,
Jani Nikula <jani.nikula@...ux.intel.com>,
Mike Marciniszyn <mike.marciniszyn@...el.com>,
Sean Hefty <sean.hefty@...el.com>,
Dimitri Sivanich <sivanich@....com>,
Boris Ostrovsky <boris.ostrovsky@...cle.com>,
Jérôme Glisse <jglisse@...hat.com>,
Radim Krčmář <rkrcmar@...hat.com>,
linux-kernel@...r.kernel.org, linux-mm@...ck.org
Subject: Re: [patch 1/2] mm, mmu_notifier: annotate mmu notifiers with
blockable invalidate callbacks
On Mon, 11 Dec 2017, Paolo Bonzini wrote:
> > Commit 4d4bbd8526a8 ("mm, oom_reaper: skip mm structs with mmu notifiers")
> > prevented the oom reaper from unmapping private anonymous memory with the
> > oom reaper when the oom victim mm had mmu notifiers registered.
> >
> > The rationale is that doing mmu_notifier_invalidate_range_{start,end}()
> > around the unmap_page_range(), which is needed, can block and the oom
> > killer will stall forever waiting for the victim to exit, which may not
> > be possible without reaping.
> >
> > That concern is real, but only true for mmu notifiers that have blockable
> > invalidate_range_{start,end}() callbacks. This patch adds a "flags" field
> > for mmu notifiers that can set a bit to indicate that these callbacks do
> > block.
>
> Why not put the flag in the ops, since the same ops should always be
> either blockable or unblockable?
>
Hi Paolo,
It certainly can be in mmu_notifier_ops, the only rationale for putting
the flags member in mmu_notifier was that it may become generally useful
later for things other than callbacks. I'm indifferent to where it is
placed and will happily move it if that's desired, absent any other
feedback on other parts of the patchset.
Thanks.
Powered by blists - more mailing lists