On Mon, 2018-07-16 at 11:10 +0200, Michal Hocko wrote: > On Fri 13-07-18 08:46:52, James Bottomley wrote: > > 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. > > This is indeed unepxected. Especially when the current LRU reclaim > balancing logic is highly pagecache biased. Are you sure you were not > running in a memcg with a small amount of the pagecache? Yes, absolutely: I just compiled and ran the programme on my laptop with no type of containment (I trust Linus, right ...) To be clear, the dirty anon push out was quite slow, so I don't think mm was using it as a serious source of reclaim, it was probably just being caught up in some other page clearing process. James -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
