On Tue 17-09-19 14:35:50, Kirill A. Shutemov wrote: > 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 I didn't say exact. All I am saying is that the more imprecise it will be the harder it is for admin to make any sense of the value. > For start, try to handle sanely trylock_page() failure under ptl while > dealing with FOLL_MLOCK. There are likely cases when accounting is problematic/impossible. But those should be a minority. > > 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. Thanks this documentation helps. I was worried there is something more going on. -- Michal Hocko SUSE Labs
