[
https://issues.apache.org/jira/browse/TS-3401?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14334450#comment-14334450
]
John Plevyak commented on TS-3401:
----------------------------------
I generally agree, but it is true that aio_thread_main() uses
ink_atomiclist_popall() to grab the entire atomic queue associated with a
AIO_Req for a single file descriptor/disk. This means that a bunch of reads
could be blocked behind the disk operation (as well as acquiring the mutex for
write callbacks, but that is probably less important). We could switch to
using ink_atomiclist_pop in aio_move which would cause only a single op to be
moved to the local queue.
That said, we should probably reexamine using linux native AIO now that the
eventfd code has landed. I think it will be more efficient, and the new linux
multi-queue support for SSDs we can do millions of ops/sec, so we want to be
able to load up that queue and native AIO with eventfd looks like a good way to
do it.
We should also consider changing all the delay periods (e.g. AIO_PERIOD) to be
100 mseconds or more if we have eventfd as we don't need to busy poll
anything... we will be awoken if anything appears in a queue or on an file
descriptor.
> AIO blocks under lock contention
> --------------------------------
>
> Key: TS-3401
> URL: https://issues.apache.org/jira/browse/TS-3401
> Project: Traffic Server
> Issue Type: Bug
> Components: Core
> Reporter: Brian Geffon
> Assignee: Brian Geffon
> Attachments: aio.patch
>
>
> In {{aio_thread_main()}} while trying to process AIO ops the AIO thread will
> wait on the mutex for the op which obviously blocks other AIO ops from
> processing. We should use a try lock instead and reschedule the ops that we
> couldn't immediately process. Patch attached. Waiting for reviews.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
