From: Avi Kivity <[email protected]>
To: [email protected]
Subject: IORING_OP_POLL_ADD slower than linux-aio IOCB_CMD_POLL
Date: Tue, 19 Apr 2022 14:07:36 +0300 [thread overview]
Message-ID: <[email protected]> (raw)
A simple webserver shows about 5% loss compared to linux-aio.
I expect the loss is due to an optimization that io_uring lacks - inline
completion vs workqueue completion:
static int aio_poll_wake(struct wait_queue_entry *wait, unsigned mode,
int sync,
void *key)
{
struct poll_iocb *req = container_of(wait, struct poll_iocb, wait);
struct aio_kiocb *iocb = container_of(req, struct aio_kiocb, poll);
__poll_t mask = key_to_poll(key);
unsigned long flags;
/* for instances that support it check for an event match first: */
if (mask && !(mask & req->events))
return 0;
/*
* Complete the request inline if possible. This requires that
three
* conditions be met:
* 1. An event mask must have been passed. If a plain wakeup
was done
* instead, then mask == 0 and we have to call vfs_poll()
to get
* the events, so inline completion isn't possible.
* 2. The completion work must not have already been scheduled.
* 3. ctx_lock must not be busy. We have to use trylock
because we
* already hold the waitqueue lock, so this inverts the normal
* locking order. Use irqsave/irqrestore because not all
* filesystems (e.g. fuse) call this function with IRQs
disabled,
* yet IRQs have to be disabled before ctx_lock is obtained.
*/
if (mask && !req->work_scheduled &&
spin_trylock_irqsave(&iocb->ki_ctx->ctx_lock, flags)) {
struct kioctx *ctx = iocb->ki_ctx;
list_del_init(&req->wait.entry);
list_del(&iocb->ki_list);
iocb->ki_res.res = mangle_poll(mask);
if (iocb->ki_eventfd && !eventfd_signal_allowed()) {
iocb = NULL;
INIT_WORK(&req->work, aio_poll_put_work);
schedule_work(&req->work);
}
spin_unlock_irqrestore(&ctx->ctx_lock, flags);
if (iocb)
iocb_put(iocb);
} else {
next reply other threads:[~2022-04-19 11:07 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-04-19 11:07 Avi Kivity [this message]
2022-04-19 11:38 ` IORING_OP_POLL_ADD slower than linux-aio IOCB_CMD_POLL Jens Axboe
2022-04-19 11:57 ` Avi Kivity
2022-04-19 12:04 ` Jens Axboe
2022-04-19 12:21 ` Avi Kivity
2022-04-19 12:31 ` Jens Axboe
2022-04-19 15:21 ` Jens Axboe
2022-04-19 15:51 ` Avi Kivity
2022-04-19 17:14 ` Jens Axboe
2022-04-19 19:41 ` Avi Kivity
2022-04-19 19:58 ` Jens Axboe
2022-04-20 11:55 ` Avi Kivity
2022-04-20 12:09 ` Jens Axboe
2022-04-21 9:05 ` Avi Kivity
2022-06-15 10:12 ` Avi Kivity
2022-06-15 10:48 ` Pavel Begunkov
2022-06-15 11:04 ` Avi Kivity
2022-06-15 11:07 ` Avi Kivity
2022-06-15 11:38 ` Pavel Begunkov
2022-06-15 12:21 ` Jens Axboe
2022-06-15 13:43 ` Avi Kivity
2022-06-15 11:30 ` Pavel Begunkov
2022-06-15 11:36 ` Avi Kivity
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 \
[email protected] \
[email protected] \
[email protected] \
/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