On Thu, Nov 09, 2017 at 11:32:46AM +0100, Jan Kara wrote: > On Wed 08-11-17 14:00:58, Josef Bacik wrote: > > From: Josef Bacik <jbacik@xxxxxx> > > > > Provide a mechanism for file systems to indicate how much dirty metadata they > > are holding. This introduces a few things > > > > 1) Zone stats for dirty metadata, which is the same as the NR_FILE_DIRTY. > > 2) WB stat for dirty metadata. This way we know if we need to try and call into > > the file system to write out metadata. This could potentially be used in the > > future to make balancing of dirty pages smarter. > > > > Signed-off-by: Josef Bacik <jbacik@xxxxxx> > ... > > diff --git a/mm/vmscan.c b/mm/vmscan.c > > index 13d711dd8776..0281abd62e87 100644 > > --- a/mm/vmscan.c > > +++ b/mm/vmscan.c > > @@ -3827,7 +3827,8 @@ static unsigned long node_pagecache_reclaimable(struct pglist_data *pgdat) > > > > /* If we can't clean pages, remove dirty pages from consideration */ > > if (!(node_reclaim_mode & RECLAIM_WRITE)) > > - delta += node_page_state(pgdat, NR_FILE_DIRTY); > > + delta += node_page_state(pgdat, NR_FILE_DIRTY) + > > + node_page_state(pgdat, NR_METADATA_DIRTY); > > > > /* Watch for any possible underflows due to delta */ > > if (unlikely(delta > nr_pagecache_reclaimable)) > > Do you expect your metadata pages to be accounted in NR_FILE_PAGES? > Otherwise this doesn't make sense. And even if they would, this function is > about kswapd / direct page reclaim and I don't think you've added smarts > there to writeout metadata. So if your metadata pages are going to show up > in NR_FILE_PAGES, you need to subtract NR_METADATA_DIRTY from reclaimable > pages always. It would be good to see btrfs counterpart to these patches so > that we can answer questions like this easily... > Ah good point, this accounting doesn't belong here, I'll fix it up. I haven't been sending the btrfs patch because it's fucking huge, since untangling the btree inode usage requires a lot of reworking all at once so it's actually buildable, so it didn't seem useful for the larger non-btrfs audience. You can see it in my git tree here https://git.kernel.org/pub/scm/linux/kernel/git/josef/btrfs-next.git/commit/?h=new-kill-btree-inode&id=5dfd4a0012c1253260da07bee3fa3d4c13aac616 I'll fix this up. Thanks, Josef -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>
