From: Brian Foster <bfoster@redhat.com> To: Dave Chinner <david@fromorbit.com> Cc: linux-xfs@vger.kernel.org, linux-mm@kvack.org, linux-fsdevel@vger.kernel.org Subject: Re: [PATCH 04/26] xfs: Improve metadata buffer reclaim accountability Date: Mon, 14 Oct 2019 09:05:09 -0400 Message-ID: <20191014130509.GA12380@bfoster> (raw) In-Reply-To: <20191013031450.GT16973@dread.disaster.area> On Sun, Oct 13, 2019 at 02:14:50PM +1100, Dave Chinner wrote: > On Sat, Oct 12, 2019 at 08:05:58AM -0400, Brian Foster wrote: > > On Sat, Oct 12, 2019 at 10:13:23AM +1100, Dave Chinner wrote: > > > On Fri, Oct 11, 2019 at 08:39:39AM -0400, Brian Foster wrote: > > > > On Wed, Oct 09, 2019 at 02:21:02PM +1100, Dave Chinner wrote: > > > > > From: Dave Chinner <dchinner@redhat.com> > > > > > > > > > > The buffer cache shrinker frees more than just the xfs_buf slab > > > > > objects - it also frees the pages attached to the buffers. Make sure > > > > > the memory reclaim code accounts for this memory being freed > > > > > correctly, similar to how the inode shrinker accounts for pages > > > > > freed from the page cache due to mapping invalidation. > > > > > > > > > > We also need to make sure that the mm subsystem knows these are > > > > > reclaimable objects. We provide the memory reclaim subsystem with a > > > > > a shrinker to reclaim xfs_bufs, so we should really mark the slab > > > > > that way. > > > > > > > > > > We also have a lot of xfs_bufs in a busy system, spread them around > > > > > like we do inodes. > > > > > > > > > > Signed-off-by: Dave Chinner <dchinner@redhat.com> > > > > > --- > > > > > > > > Seems reasonable, but for inodes we also spread the ili zone. Should we > > > > not be consistent with bli's as well? > > > > > > bli's are reclaimed when the buffer is cleaned. ili's live for the > > > live of the inode in cache. Hence bli's are short term allocations > > > (much shorter than xfs_bufs they attach to) and are reclaimed much > > > faster than inodes and their ilis. There's also a lot less blis than > > > ili's, so the spread of their footprint across memory nodes doesn't > > > matter that much. Local access for the memcpy during formatting is > > > probably more important than spreading the memory usage of them > > > these days, anyway. > > > > > > > Yes, the buffer/inode lifecycle difference is why why I presume bli > > zones are not ZONE_RECLAIM like ili zones. > > No, that is not the case. IO completion cleaning the buffer is what > frees the bli. The ili can only be freed by reclaiming the inode, so > it's memory that can only be returned to the free pool by running a > shrinker. Hence ilis are ZONE_RECLAIM to account them as memory that > can be reclaimed through shrinker invocation, while BLIs are not > because memory reclaim can't directly cause them to be freed. > That is pretty much what I said. I think we're in agreement. > > This doesn't tell me anything about why buffers should be spread > > around as such and buffer log items not, though.. > > xfs_bufs are long lived, are global structures, and can accumulate > in the millions if the workload requires it. IOWs, we should spread > xfs_bufs for exactly the same reasons inodes are spread. > > As for BLIs, they are short term structures - a single xfs_buf might > have thousands of different blis attached to it over it's life in > the cache because the BLI is freed when the buffer is cleaned. > Short term relative to the ILI perhaps, but these are still memory allocations that outlive the allocating task returning to userspace, are reused (across tasks) commonly enough and have an I/O bound life cycle. That's also not considering page/slab buildup in the kmem cache beyond the lifetime of individual allocations.. > We don't need to spread small short term structures around NUMA > memory nodes because they don't present a long term memory imbalance > vector. In general it is better to have them allocated local to the > process that is using them where the memory access latency is > lowest, knowing that they will be freed shortly and not contribute > to long term memory usage. > Hmm.. doesn't this all depend on enablement of a cgroup knob in the first place? It looks to me that this behavior is tied to a per-task state (not a per-mount or zone setting, which just allows such behavior on the zone) where the controller has explicitly requested us to not perform sustained allocations in the local node if possible. Instead, spread slab allocations around at the cost of bypassing this local allocation heuristic, presumably because $application wants prioritized access to that memory. What am I missing? BTW, it also looks like this is only relevant for slab. I don't see any references in slub (or slob), but I haven't dug too deeply.. Brian > Cheers, > > Dave. > -- > Dave Chinner > david@fromorbit.com
next prev parent reply index Thread overview: 87+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-10-09 3:20 [PATCH V2 00/26] mm, xfs: non-blocking inode reclaim Dave Chinner 2019-10-09 3:20 ` [PATCH 01/26] xfs: Lower CIL flush limit for large logs Dave Chinner 2019-10-11 12:39 ` Brian Foster 2019-10-30 17:08 ` Darrick J. Wong 2019-10-09 3:21 ` [PATCH 02/26] xfs: Throttle commits on delayed background CIL push Dave Chinner 2019-10-11 12:38 ` Brian Foster 2019-10-09 3:21 ` [PATCH 03/26] xfs: don't allow log IO to be throttled Dave Chinner 2019-10-11 9:35 ` Christoph Hellwig 2019-10-11 12:39 ` Brian Foster 2019-10-30 17:14 ` Darrick J. Wong 2019-10-09 3:21 ` [PATCH 04/26] xfs: Improve metadata buffer reclaim accountability Dave Chinner 2019-10-11 12:39 ` Brian Foster 2019-10-11 12:57 ` Christoph Hellwig 2019-10-11 23:14 ` Dave Chinner 2019-10-11 23:13 ` Dave Chinner 2019-10-12 12:05 ` Brian Foster 2019-10-13 3:14 ` Dave Chinner 2019-10-14 13:05 ` Brian Foster [this message] 2019-10-30 17:25 ` Darrick J. Wong 2019-10-30 21:43 ` Dave Chinner 2019-10-31 3:06 ` Darrick J. Wong 2019-10-31 20:50 ` Dave Chinner 2019-10-31 21:05 ` Darrick J. Wong 2019-10-31 21:22 ` Christoph Hellwig 2019-11-03 21:26 ` Dave Chinner 2019-11-04 23:08 ` Darrick J. Wong 2019-10-09 3:21 ` [PATCH 05/26] xfs: correctly acount for reclaimable slabs Dave Chinner 2019-10-11 12:39 ` Brian Foster 2019-10-30 17:16 ` Darrick J. Wong 2019-10-09 3:21 ` [PATCH 06/26] xfs: synchronous AIL pushing Dave Chinner 2019-10-11 9:42 ` Christoph Hellwig 2019-10-11 12:40 ` Brian Foster 2019-10-11 23:15 ` Dave Chinner 2019-10-09 3:21 ` [PATCH 07/26] xfs: tail updates only need to occur when LSN changes Dave Chinner 2019-10-11 9:50 ` Christoph Hellwig 2019-10-11 12:40 ` Brian Foster 2019-10-09 3:21 ` [PATCH 08/26] mm: directed shrinker work deferral Dave Chinner 2019-10-14 8:46 ` Christoph Hellwig 2019-10-14 13:06 ` Brian Foster 2019-10-18 7:59 ` Dave Chinner 2019-10-09 3:21 ` [PATCH 09/26] shrinkers: use defer_work for GFP_NOFS sensitive shrinkers Dave Chinner 2019-10-09 3:21 ` [PATCH 10/26] mm: factor shrinker work calculations Dave Chinner 2019-10-09 3:21 ` [PATCH 11/26] shrinker: defer work only to kswapd Dave Chinner 2019-10-09 3:21 ` [PATCH 12/26] shrinker: clean up variable types and tracepoints Dave Chinner 2019-10-09 3:21 ` [PATCH 13/26] mm: reclaim_state records pages reclaimed, not slabs Dave Chinner 2019-10-09 3:21 ` [PATCH 14/26] mm: back off direct reclaim on excessive shrinker deferral Dave Chinner 2019-10-11 16:21 ` Matthew Wilcox 2019-10-11 23:20 ` Dave Chinner 2019-10-09 3:21 ` [PATCH 15/26] mm: kswapd backoff for shrinkers Dave Chinner 2019-10-09 3:21 ` [PATCH 16/26] xfs: synchronous AIL pushing Dave Chinner 2019-10-11 10:18 ` Christoph Hellwig 2019-10-11 15:29 ` Brian Foster 2019-10-11 23:27 ` Dave Chinner 2019-10-12 12:08 ` Brian Foster 2019-10-09 3:21 ` [PATCH 17/26] xfs: don't block kswapd in inode reclaim Dave Chinner 2019-10-11 15:29 ` Brian Foster 2019-10-09 3:21 ` [PATCH 18/26] xfs: reduce kswapd blocking on inode locking Dave Chinner 2019-10-11 10:29 ` Christoph Hellwig 2019-10-09 3:21 ` [PATCH 19/26] xfs: kill background reclaim work Dave Chinner 2019-10-11 10:31 ` Christoph Hellwig 2019-10-09 3:21 ` [PATCH 20/26] xfs: use AIL pushing for inode reclaim IO Dave Chinner 2019-10-11 17:38 ` Brian Foster 2019-10-09 3:21 ` [PATCH 21/26] xfs: remove mode from xfs_reclaim_inodes() Dave Chinner 2019-10-11 10:39 ` Christoph Hellwig 2019-10-14 13:07 ` Brian Foster 2019-10-09 3:21 ` [PATCH 22/26] xfs: track reclaimable inodes using a LRU list Dave Chinner 2019-10-11 10:42 ` Christoph Hellwig 2019-10-14 13:07 ` Brian Foster 2019-10-09 3:21 ` [PATCH 23/26] xfs: reclaim inodes from the LRU Dave Chinner 2019-10-11 10:56 ` Christoph Hellwig 2019-10-30 23:25 ` Dave Chinner 2019-10-09 3:21 ` [PATCH 24/26] xfs: remove unusued old inode reclaim code Dave Chinner 2019-10-09 3:21 ` [PATCH 25/26] xfs: rework unreferenced inode lookups Dave Chinner 2019-10-11 12:55 ` Christoph Hellwig 2019-10-11 13:39 ` Peter Zijlstra 2019-10-11 23:38 ` Dave Chinner 2019-10-14 13:07 ` Brian Foster 2019-10-17 1:24 ` Dave Chinner 2019-10-17 7:57 ` Brian Foster 2019-10-18 20:29 ` Dave Chinner 2019-10-09 3:21 ` [PATCH 26/26] xfs: use xfs_ail_push_all_sync in xfs_reclaim_inodes Dave Chinner 2019-10-11 9:55 ` Christoph Hellwig 2019-10-09 7:06 ` [PATCH V2 00/26] mm, xfs: non-blocking inode reclaim Christoph Hellwig 2019-10-11 19:03 ` Josef Bacik 2019-10-11 23:48 ` Dave Chinner 2019-10-12 0:19 ` Josef Bacik 2019-10-12 0:48 ` Dave Chinner
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20191014130509.GA12380@bfoster \ --to=bfoster@redhat.com \ --cc=david@fromorbit.com \ --cc=linux-fsdevel@vger.kernel.org \ --cc=linux-mm@kvack.org \ --cc=linux-xfs@vger.kernel.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
Linux-XFS Archive on lore.kernel.org Archives are clonable: git clone --mirror https://lore.kernel.org/linux-xfs/0 linux-xfs/git/0.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 linux-xfs linux-xfs/ https://lore.kernel.org/linux-xfs \ linux-xfs@vger.kernel.org public-inbox-index linux-xfs Example config snippet for mirrors Newsgroup available over NNTP: nntp://nntp.lore.kernel.org/org.kernel.vger.linux-xfs AGPL code for this site: git clone https://public-inbox.org/public-inbox.git