On Wed, Jan 20, 2016 at 04:56:30PM -0500, Benjamin LaHaise wrote:
On Thu, Jan 21, 2016 at 08:45:46AM +1100, Dave Chinner wrote:
quoted
Filesystems *must take locks* in the IO path. We have to serialise
against truncate and other operations at some point in the IO path
(e.g. block mapping vs concurrent allocation and/or removal), and
that can only be done sanely with sleeping locks. There is no way
of knowing in advance if we are going to block, and so either we
always use threads for IO submission or we accept that occasionally
the AIO submission will block.
I never said we don't take locks. Still, we can be more intelligent
about when and where we do so. With the nonblocking pread() and pwrite()
changes being proposed elsewhere, we can do the part of the I/O that
doesn't block in the submitter, which is a huge win when possible.
As it stands today, *every* buffered write takes i_mutex immediately
on entering ->write(). That one issue alone accounts for a nearly 10x
performance difference between an O_SYNC write and an O_DIRECT write,
Yes, that locking is for correct behaviour, not for performance
reasons. The i_mutex is providing the required semantics for POSIX
write(2) functionality - writes must serialise against other reads
and writes so that they are completed atomically w.r.t. other IO.
i.e. writes to the same offset must not interleave, not should reads
be able to see partial data from a write in progress.
Direct IO does not conform to POSIX concurrency standards, so we
don't have to serialise concurrent IO against each other.
and using O_SYNC writes is a legitimate use-case for users who want
caching of data by the kernel (duplicating that functionality is a huge
amount of work for an application, plus if you want the cache to be
persistent between runs of an app, you have to get the kernel to do it).
Yes, but you take what you get given. Buffered IO sucks in many ways;
this is just one of them.
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com