Thread (51 messages) 51 messages, 10 authors, 2016-03-20

Re: [PATCH 07/13] aio: enabled thread based async fsync

From: Dave Chinner <hidden>
Date: 2016-01-20 21:57:03
Also in: linux-fsdevel, linux-mm, lkml

On Wed, Jan 20, 2016 at 12:29:32PM -0800, Linus Torvalds wrote:
On Wed, Jan 20, 2016 at 11:59 AM, Dave Chinner [off-list ref] wrote:
quoted
quoted
Are there other users outside of Solace? It would be good to get comments..
I know of quite a few storage/db products that use AIO. The most
recent high profile project that have been reporting issues with AIO
on XFS is http://www.scylladb.com/. That project is architected
around non-blocking AIO for scalability reasons...
I was more wondering about the new interfaces, making sure that the
feature set actually matches what people want to do..
Well, they have mentioned that openat() can block, as will the first
operation after open that requires reading the file extent map from
disk. There are some ways of hacking around this (e.g. running
FIEMAP with a zero extent count or ext4's special extent prefetch
ioctl in a separate thread to prefetch the extent list into memory
before IO is required) so I suspect we may actually need some
interfaces that don't current exist at all....
That said, I also agree that it would be interesting to hear what the
performance impact is for existing performance-sensitive users. Could
we make that "aio_may_use_threads()" case be unconditional, making
things simpler?
That would make things a lot simpler in the kernel and AIO
submission a lot more predictable/deterministic for userspace. I'd
suggest that, at minimum, it should be the default behaviour...

Cheers,

Dave.
-- 
Dave Chinner
david-FqsqvQoI3Ljby3iVrkZq2A@public.gmane.org
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help