From: Josef Bacik <josef@toxicpanda.com>
To: Dave Chinner <david@fromorbit.com>
Cc: Josef Bacik <josef@toxicpanda.com>,
hannes@cmpxchg.org, linux-mm@kvack.org,
akpm@linux-foundation.org, jack@suse.cz,
linux-fsdevel@vger.kernel.org, kernel-team@fb.com,
linux-btrfs@vger.kernel.org, Josef Bacik <jbacik@fb.com>
Subject: Re: [PATCH 2/6] writeback: allow for dirty metadata accounting
Date: Fri, 10 Nov 2017 12:11:12 -0500 [thread overview]
Message-ID: <20171110171111.idzazbjs26vh7nnb@destiny> (raw)
In-Reply-To: <20171110042533.GT4094@dastard>
On Fri, Nov 10, 2017 at 03:25:33PM +1100, Dave Chinner wrote:
> On Thu, Nov 09, 2017 at 02:30:57PM -0500, Josef Bacik wrote:
> > From: Josef Bacik <jbacik@fb.com>
> >
> > 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.
>
> Ok, so when you have 64k page size and 4k metadata block size and
> you're using kmalloc() to allocate the storage for the metadata,
> how do we make use of all this page-based metadata accounting
> stuff?
Sigh, I completely fucked this up. I just found whatever my most recent local
branch was, forward ported it, and have been testing it for a few weeks to make
sure it was rock solid and sent it out. I completely forgot I had redone all of
this stuff to count with bytes instead of pages specifically for this use case.
I have no idea where those patches went in my local tree but I've pulled down
the most recent versions of the patches from the mailinglist and will start
hammering on those again. Sorry,
Josef
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2017-11-10 17:11 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-11-09 19:30 [PATCH 1/6] remove mapping from balance_dirty_pages*() Josef Bacik
2017-11-09 19:30 ` [PATCH 2/6] writeback: allow for dirty metadata accounting Josef Bacik
2017-11-10 4:25 ` Dave Chinner
2017-11-10 17:11 ` Josef Bacik [this message]
2017-11-09 19:30 ` [PATCH 3/6] writeback: introduce super_operations->write_metadata Josef Bacik
2017-11-09 19:30 ` [PATCH 4/6] export radix_tree_iter_tag_set Josef Bacik
2017-11-09 19:31 ` [PATCH 5/6] Btrfs: kill the btree_inode Josef Bacik
2017-11-09 19:31 ` [PATCH 6/6] btrfs: rework end io for extent buffer reads Josef Bacik
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=20171110171111.idzazbjs26vh7nnb@destiny \
--to=josef@toxicpanda.com \
--cc=akpm@linux-foundation.org \
--cc=david@fromorbit.com \
--cc=hannes@cmpxchg.org \
--cc=jack@suse.cz \
--cc=jbacik@fb.com \
--cc=kernel-team@fb.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-mm@kvack.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
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