From: Theodore Ts'o <tytso@mit.edu>
To: Christoph Hellwig <hch@infradead.org>
Cc: Ext4 Developers List <linux-ext4@vger.kernel.org>,
Jan Kara <jack@suse.cz>,
linux-fsdevel@vger.kernel.org
Subject: Re: [PATCH] ext4: optimize ext4 direct I/O locking for reading
Date: Wed, 21 Sep 2016 10:37:48 -0400 [thread overview]
Message-ID: <20160921143748.xswkovbjrtcgs3bq@thunk.org> (raw)
In-Reply-To: <20160921132609.GA30232@infradead.org>
On Wed, Sep 21, 2016 at 06:26:09AM -0700, Christoph Hellwig wrote:
> Is there any chance you could look into simplifying the locking instead
> of making it even more complicated? Since Al replaced i_mutex with
> i_rwsem you can now easily take that in shared mode. E.g. if you'd
> move to a direct I/O model closer to XFS, ocfs2 and NFS where you always
> take i_rwsem in shared mode you'll get the scalibility of the
> dioread_nolock case while no having to do these crazy dances, and you
> can also massively simplify the codebase. Similarly you can demote it
> from exclusive to shared after allocating blocks in the write path,
> and you'll end up with something way easier to understand.
Unfortunately, in order to do this we need to extend the
dioread_nolock handling for sub-page block sizes. (This is where we
insert the allocated blocks into the extent maps marked uninitialized,
and only converting the extent from uninitialized to initialized ---
which today only works when the page size == block size.)
This is on my todo list, but half of the problem is the mess caused by
needing to iterate over the circularly linked buffer heads when there
are multiple buffer heads covering the page. I was originally
assuming that it would be easier to fix this after doing the bh ->
iomap conversion, but it's in a while before I looked into this
particular change. I can try to take a closer look again....
The main reason why I looked into this hack --- and I will be the
first to agree it was a hack, is because I had a request to support
the dioread_nolock scalability on a Little Endian PowerPC system which
has 64k page sizes.
> Sorry for the rant, but I just had to dig into this code when looking
> at converting ext4 to the new DAX path, and my eyes still bleed..
Yeah, I know, and I'm sorry. There's quite a bit of technical debt
there, which I do want to clean up.
- Ted
next prev parent reply other threads:[~2016-09-21 15:14 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-09-21 5:27 [PATCH] ext4: optimize ext4 direct I/O locking for reading Theodore Ts'o
2016-09-21 13:26 ` Christoph Hellwig
2016-09-21 14:37 ` Theodore Ts'o [this message]
2016-09-22 12:31 ` Jan Kara
2016-09-22 13:18 ` Christoph Hellwig
2016-09-22 13:30 ` Theodore Ts'o
2016-09-30 5:22 ` Theodore Ts'o
2016-10-03 7:41 ` 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=20160921143748.xswkovbjrtcgs3bq@thunk.org \
--to=tytso@mit.edu \
--cc=hch@infradead.org \
--cc=jack@suse.cz \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-fsdevel@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
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.