From: Jan Kara <jack@suse.cz>
To: Josef Bacik <jbacik@fb.com>
Cc: linux-btrfs@vger.kernel.org, linux-fsdevel@vger.kernel.org,
	kernel-team@fb.com, jack@suse.com, viro@zeniv.linux.org.uk,
	dchinner@redhat.com, hch@lst.de
Subject: Re: [PATCH 2/2] writeback: allow for dirty metadata accounting
Date: Wed, 10 Aug 2016 12:09:57 +0200	[thread overview]
Message-ID: <20160810100957.GC12157@quack2.suse.cz> (raw)
In-Reply-To: <1470769707-26079-3-git-send-email-jbacik@fb.com>
On Tue 09-08-16 15:08:27, Josef Bacik wrote:
> 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.
> 3) A super callback to handle writing back dirty metadata.
> 
> A future patch will take advantage of this work in btrfs.  Thanks,
Hum, I once had a patch to allow filesystems to hook more into writeback
where a filesystem was just asked to do writeback and it could decide what
to do with it (it could use generic helpers to essentially replicate what
current writeback code does) but it could also choose some smarter strategy
of picking inodes to write. This scheme could easily accommodate your
metadata writeback as well and there are also other uses for it. But that
patch got broken by Tejun's cgroup aware writeback so one would have to
start from scratch.
We certainly have to think how to integrate this with cgroup aware
writeback. I guess your ->writeback_metadata() just does not bother and would
write anything in the root cgroup, right? After all you don't even pass the
information for which memcg the metadata writeback should be performed down
to the fs callback (that is encoded in the bdi_writeback structure). And
for now I think we could get away with that although it would need to be
handled properly in future I think.
If we created a generic filesystem writeback callback as I suggest, proper
integration with memcg writeback in unavoidable. But I have to think how to
do that best.
								Honza
-- 
Jan Kara <jack@suse.com>
SUSE Labs, CR
next prev parent reply	other threads:[~2016-08-10 18:03 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-08-09 19:08 [PATCH 0/2][RFC] Provide accounting for dirty metadata Josef Bacik
2016-08-09 19:08 ` [PATCH 1/2] remove mapping from balance_dirty_pages*() Josef Bacik
2016-08-09 19:30   ` kbuild test robot
2016-08-09 19:32   ` kbuild test robot
2016-08-09 20:12   ` kbuild test robot
2016-08-09 20:50   ` kbuild test robot
2016-08-10  8:27   ` Jan Kara
2016-08-10  8:29     ` Jan Kara
2016-08-10 19:56   ` Tejun Heo
2016-08-09 19:08 ` [PATCH 2/2] writeback: allow for dirty metadata accounting Josef Bacik
2016-08-10 10:09   ` Jan Kara [this message]
2016-08-10 14:05     ` Josef Bacik
2016-08-10 20:12   ` Tejun Heo
2016-08-10 21:16     ` Josef Bacik
2016-08-10 21:39       ` Tejun Heo
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=20160810100957.GC12157@quack2.suse.cz \
    --to=jack@suse.cz \
    --cc=dchinner@redhat.com \
    --cc=hch@lst.de \
    --cc=jack@suse.com \
    --cc=jbacik@fb.com \
    --cc=kernel-team@fb.com \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=viro@zeniv.linux.org.uk \
    /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
  Be sure your reply has a Subject: header at the top and a blank line
  before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).