[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190917113550.v6nool7oizht66fx@box>
Date: Tue, 17 Sep 2019 14:35:50 +0300
From: "Kirill A. Shutemov" <kirill@...temov.name>
To: Michal Hocko <mhocko@...nel.org>
Cc: Lucian Adrian Grijincu <lucian@...com>, linux-mm@...ck.org,
Souptick Joarder <jrdr.linux@...il.com>,
linux-kernel@...r.kernel.org,
Andrew Morton <akpm@...ux-foundation.org>,
Rik van Riel <riel@...com>, Roman Gushchin <guro@...com>
Subject: Re: [PATCH v3] mm: memory: fix /proc/meminfo reporting for
MLOCK_ONFAULT
On Tue, Sep 17, 2019 at 12:15:19PM +0200, Michal Hocko wrote:
> On Mon 16-09-19 18:26:19, Kirill A. Shutemov wrote:
> > On Fri, Sep 13, 2019 at 02:11:19PM -0700, Lucian Adrian Grijincu wrote:
> > > As pages are faulted in MLOCK_ONFAULT correctly updates
> > > /proc/self/smaps, but doesn't update /proc/meminfo's Mlocked field.
> >
> > I don't think there's something wrong with this behaviour. It is okay to
> > keep the page an evictable LRU list (and not account it to NR_MLOCKED).
>
> evictable list is an implementation detail. Having an overview about an
s/evictable/unevictable/
> amount of mlocked pages can be important. Lazy accounting makes this
> more fuzzy and harder for admins to monitor.
>
> Sure it is not a bug to panic about but it certainly makes life of poor
> admins harder.
Good luck with making mlock accounting exact :P
For start, try to handle sanely trylock_page() failure under ptl while
dealing with FOLL_MLOCK.
> If there is a pathological THP behavior possible then we should look
> into that as well.
There's nothing pathological about THP behaviour. See "MLOCKING
Transparent Huge Pages" section in Documentation/vm/unevictable-lru.rst.
--
Kirill A. Shutemov
Powered by blists - more mailing lists