From: Jan Kara <jack@suse.cz>
To: "Wilcox, Matthew R" <matthew.r.wilcox@intel.com>
Cc: Jan Kara <jack@suse.cz>,
"ross.zwisler@linux.intel.com" <ross.zwisler@linux.intel.com>,
"akpm@linux-foundation.org" <akpm@linux-foundation.org>,
"Dilger, Andreas" <andreas.dilger@intel.com>,
"axboe@kernel.dk" <axboe@kernel.dk>,
"boaz@plexistor.com" <boaz@plexistor.com>,
"david@fromorbit.com" <david@fromorbit.com>,
"hch@lst.de" <hch@lst.de>,
"kirill.shutemov@linux.intel.com"
<kirill.shutemov@linux.intel.com>,
"mathieu.desnoyers@efficios.com" <mathieu.desnoyers@efficios.com>,
"rdunlap@infradead.org" <rdunlap@infradead.org>,
"tytso@mit.edu" <tytso@mit.edu>,
"mm-commits@vger.kernel.org" <mm-commits@vger.kernel.org>,
"linux-ext4@vger.kernel.org" <linux-ext4@vger.kernel.org>,
Matthew Wilcox <willy@linux.intel.com>,
xfs@oss.sgi.com
Subject: Re: + ext4-add-dax-functionality.patch added to -mm tree
Date: Tue, 17 Feb 2015 09:52:00 +0100 [thread overview]
Message-ID: <20150217085200.GA23192@quack.suse.cz> (raw)
In-Reply-To: <20150119141858.GF5662@quack.suse.cz>
Matthew, I think I still didn't see response to this. I think we can
fixup things after they are merged (since Andrew sent this patch to Linus)
but IMHO it needs some action...
Honza
On Mon 19-01-15 15:18:58, Jan Kara wrote:
> On Fri 16-01-15 21:16:03, Wilcox, Matthew R wrote:
> > On Mon 12-01-15 15:11:17, Andrew Morton wrote:
> > > > +#ifdef CONFIG_FS_DAX
> > > > +static int ext4_dax_fault(struct vm_area_struct *vma, struct vm_fault *vmf)
> > > > +{
> > > > + return dax_fault(vma, vmf, ext4_get_block);
> > > > + /* Is this the right get_block? */
> > > You can remove the comment. It is the right get_block function.
> >
> > Are you sure it shouldn't be ext4_get_block_write, or _write_nolock?
> > According to the comments, ext4_get_block() doesn't allocate
> > uninitialized extents, which we do want it to do.
> Hum, so if I understand the code right dax_fault() will allocate a block
> (== page in persistent memory) for a faulted address and will map this
> block directly into process' address space. Thus that block has to be
> zeroed out before the fault finishes no matter what (so that userspace
> doesn't see garbage) - unwritten block handling in the filesystem doesn't
> really matter (and would only cause unnecessary overhead) because of the
> direct mapping of the block to process' address space. So I would think
> that it would be easiest if dax_fault() simply zeroed out blocks which got
> allocated. You could rewrite part of dax_fault() to something like:
>
> create = !vmf->cow_page && (vmf->flags & FAULT_FLAG_WRITE);
> error = get_block(inode, block, &bh, create);
> if (!error && (bh.b_size < PAGE_SIZE))
> error = -EIO;
> if (error)
> goto unlock_page;
>
> if (buffer_new(&bh)) {
> count_vm_event(PGMAJFAULT);
> mem_cgroup_count_vm_event(vma->vm_mm, PGMAJFAULT);
> major = VM_FAULT_MAJOR;
> dax_clear_blocks(inode, bh->b_blocknr, PAGE_SIZE);
> } else if (!buffer_mapped(&bh))
> return dax_load_hole(mapping, page, vmf);
>
> Note, that we also avoided calling get_block() callback twice on major fault
> as that's relatively expensive due to locking, extent tree lookups, etc.
>
> Also note that ext2 then doesn't have to call dax_clear_blocks() at all if
> I understand the code right.
>
> And with this change to dax_fault() using ext4_get_block() is the right
> function to call. It will just allocate a block if necessary and attach it
> to an appropriate place in the extent tree which is all you need.
>
> > > > @@ -694,6 +706,11 @@ static int _ext4_get_block(struct inode
> > > >
> > > > map_bh(bh, inode->i_sb, map.m_pblk);
> > > > bh->b_state = (bh->b_state & ~EXT4_MAP_FLAGS) | map.m_flags;
> > > > + if (IS_DAX(inode) && buffer_unwritten(bh) && !io_end) {
> > > > + bh->b_assoc_map = inode->i_mapping;
> > > > + bh->b_private = (void *)(unsigned long)iblock;
> > > > + bh->b_end_io = ext4_end_io_unwritten;
> > > > + }
> > > So why is this needed? It would deserve a comment. It confuses me in
> > > particular because:
> > > 1) This is a often a phony bh used just as a container for passed data and
> > > b_end_io is just ignored.
> > > 2) Even if it was real bh attached to a page, for DAX we don't do any
> > > writeback and thus ->b_end_io will never get called?
> > > 3) And if it does get called, you certainly cannot call
> > > ext4_convert_unwritten_extents() from softirq context where ->b_end_io
> > > gets called.
> >
> > This got added to fix a problem that Dave Chinner pointed out. We need
> > the allocated extent to either be zeroed (as ext2 does), or marked as
> > unwritten (ext4, XFS) so that a racing read/page fault doesn't return
> > uninitialized data. If it's marked as unwritten, we need to convert it
> > to a written extent after we've initialised the contents. We use the
> > b_end_io() callback to do this, and it's called from the DAX code, not in
> > softirq context.
> OK, I see. But I didn't find where ->b_end_io gets called from dax code
> (specifically I don't see it anywhere in dax_do_IO() or dax_io()). Can you
> point me please?
>
> Also abusing b_end_io of a phony buffer for that looks ugly to me (we are
> trying to get away from passing phony bh around and this would entangle us
> even more into that mess). Normally I would think that end_io() callback
> passed into dax_do_io() should perform necessary conversions and for
> dax_fault() we could do necessary conversions inside foofs_page_mkwrite()...
>
> Honza
> --
> Jan Kara <jack@suse.cz>
> SUSE Labs, CR
--
Jan Kara <jack@suse.cz>
SUSE Labs, CR
next prev parent reply other threads:[~2015-02-17 8:52 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <54b45495.+RptMlNQorYE9TTf%akpm@linux-foundation.org>
2015-01-15 12:41 ` + ext4-add-dax-functionality.patch added to -mm tree Jan Kara
2015-01-16 21:16 ` Wilcox, Matthew R
2015-01-19 14:18 ` Jan Kara
2015-02-17 8:52 ` Jan Kara [this message]
2015-02-17 13:37 ` Matthew Wilcox
2015-02-18 10:40 ` Jan Kara
2015-02-18 21:55 ` Dave Chinner
2015-02-18 21:59 ` hch
2015-02-19 15:42 ` Jan Kara
2015-02-19 21:12 ` Dave Chinner
2015-02-19 23:08 ` Dave Chinner
2015-02-20 12:05 ` Jan Kara
2015-02-20 22:15 ` Matthew Wilcox
2015-02-23 12:52 ` Jan Kara
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=20150217085200.GA23192@quack.suse.cz \
--to=jack@suse.cz \
--cc=akpm@linux-foundation.org \
--cc=andreas.dilger@intel.com \
--cc=axboe@kernel.dk \
--cc=boaz@plexistor.com \
--cc=david@fromorbit.com \
--cc=hch@lst.de \
--cc=kirill.shutemov@linux.intel.com \
--cc=linux-ext4@vger.kernel.org \
--cc=mathieu.desnoyers@efficios.com \
--cc=matthew.r.wilcox@intel.com \
--cc=mm-commits@vger.kernel.org \
--cc=rdunlap@infradead.org \
--cc=ross.zwisler@linux.intel.com \
--cc=tytso@mit.edu \
--cc=willy@linux.intel.com \
--cc=xfs@oss.sgi.com \
/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).