From: "Theodore Y. Ts'o" <tytso@mit.edu>
To: Ext4 Developers List <linux-ext4@vger.kernel.org>
Cc: joseph.qi@linux.alibaba.com, Liu Bo <bo.liu@linux.alibaba.com>
Subject: Discussion: is it time to remove dioread_nolock?
Date: Thu, 26 Dec 2019 10:31:18 -0500 [thread overview]
Message-ID: <20191226153118.GA17237@mit.edu> (raw)
With inclusion of Ritesh's inode lock scalability patches[1], the
traditional performance reasons for dioread_nolock --- namely,
removing the need to take an exclusive lock for Direct I/O read
operations --- has been removed.
[1] https://lore.kernel.org/r/20191212055557.11151-1-riteshh@linux.ibm.com
So... is it time to remove the code which supports dioread_nolock?
Doing so would simplify the code base, and reduce the test matrix.
This would also make it easier to restructure the write path when
allocating blocks so that the extent tree is updated after writing out
the data blocks, by clearing away the underbrush of dioread nolock
first.
If we do this, we'd leave the dioread_nolock mount option for
backwards compatibility, but it would be a no-op and not actually do
anything.
Any objections before I look into ripping out dioread_nolock?
The one possible concern that I considered was for Alibaba, which was
doing something interesting with dioread_nolock plus nodelalloc. But
looking at Liu Bo's explanation[2], I believe that their workload
would be satisfied simply by using the standard ext4 mount options
(that is, the default mode has the performance benefits when doing
parallel DIO reads, and so the need for nodelalloc to mitigate the
tail latency concerns which Alibaba was seeing in their workload would
not be needed). Could Liu or someone from Alibaba confirm, perhaps
with some benchmarks using their workload?
[2] https://lore.kernel.org/linux-ext4/20181121013035.ab4xp7evjyschecy@US-160370MP2.local/
- Ted
next reply other threads:[~2019-12-26 15:31 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-12-26 15:31 Theodore Y. Ts'o [this message]
2019-12-27 13:10 ` Discussion: is it time to remove dioread_nolock? Joseph Qi
2019-12-29 15:03 ` Xiaoguang Wang
2020-01-06 12:24 ` Ritesh Harjani
2020-01-07 0:43 ` Theodore Y. Ts'o
2020-01-07 8:22 ` Jan Kara
2020-01-07 17:11 ` Theodore Y. Ts'o
2020-01-07 17:22 ` Jan Kara
2020-01-08 10:45 ` Ritesh Harjani
2020-01-08 17:42 ` Theodore Y. Ts'o
2020-01-09 9:21 ` Ritesh Harjani
2020-01-09 16:38 ` Theodore Y. Ts'o
2020-01-14 23:30 ` Ritesh Harjani
2020-01-15 16:48 ` Theodore Y. Ts'o
2020-01-16 9:46 ` Ritesh Harjani
2020-01-09 12:34 ` 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=20191226153118.GA17237@mit.edu \
--to=tytso@mit.edu \
--cc=bo.liu@linux.alibaba.com \
--cc=joseph.qi@linux.alibaba.com \
--cc=linux-ext4@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 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).