From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Message-ID: <1531496812.3361.9.camel@HansenPartnership.com> Subject: Re: [PATCH v6 0/7] fs/dcache: Track & limit # of negative dentries From: James Bottomley To: Dave Chinner Cc: Linus Torvalds , Matthew Wilcox , Waiman Long , Michal Hocko , Al Viro , Jonathan Corbet , "Luis R. Rodriguez" , Kees Cook , Linux Kernel Mailing List , linux-fsdevel , linux-mm , "open list:DOCUMENTATION" , Jan Kara , Paul McKenney , Andrew Morton , Ingo Molnar , Miklos Szeredi , Larry Woodman , "Wangkai (Kevin,C)" Date: Fri, 13 Jul 2018 08:46:52 -0700 In-Reply-To: <20180713003614.GW2234@dastard> References: <9f24c043-1fca-ee86-d609-873a7a8f7a64@redhat.com> <1531330947.3260.13.camel@HansenPartnership.com> <18c5cbfe-403b-bb2b-1d11-19d324ec6234@redhat.com> <1531336913.3260.18.camel@HansenPartnership.com> <4d49a270-23c9-529f-f544-65508b6b53cc@redhat.com> <1531411494.18255.6.camel@HansenPartnership.com> <20180712164932.GA3475@bombadil.infradead.org> <1531416080.18255.8.camel@HansenPartnership.com> <1531425435.18255.17.camel@HansenPartnership.com> <20180713003614.GW2234@dastard> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: owner-linux-mm@kvack.org List-ID: On Fri, 2018-07-13 at 10:36 +1000, Dave Chinner wrote: > On Thu, Jul 12, 2018 at 12:57:15PM -0700, James Bottomley wrote: > > What surprises me most about this behaviour is the steadiness of > > the page cache ... I would have thought we'd have shrunk it > > somewhat given the intense call on the dcache. > > Oh, good, the page cache vs superblock shrinker balancing still > protects the working set of each cache the way it's supposed to > under heavy single cache pressure. :) Well, yes, but my expectation is most of the page cache is clean, so easily reclaimable. I suppose part of my surprise is that I expected us to reclaim the clean caches first before we started pushing out the dirty stuff and reclaiming it. I'm not saying it's a bad thing, just saying I didn't expect us to make such good decisions under the parameters of this test. > Keep in mind that the amount of work slab cache shrinkers perform is > directly proportional to the amount of page cache reclaim that is > performed and the size of the slab cache being reclaimed.  IOWs, > under a "single cache pressure" workload we should be directing > reclaim work to the huge cache creating the pressure and do very > little reclaim from other caches.... That definitely seems to happen. The thing I was most surprised about is the steady pushing of anonymous objects to swap. I agree the dentry cache doesn't seem to be growing hugely after the initial jump, so it seems to be the largest source of reclaim. > [ What follows from here is conjecture, but is based on what I've > seen in the past 10+ years on systems with large numbers of negative > dentries and fragmented dentry/inode caches. ] OK, so I fully agree with the concern about pathological object vs page freeing problems (I referred to it previously). However, I did think the compaction work that's been ongoing in mm was supposed to help here? James