All of lore.kernel.org
 help / color / mirror / Atom feed
From: Josh Durgin <jdurgin@redhat.com>
To: Haomai Wang <haomaiwang@gmail.com>,
	"ceph-devel@vger.kernel.org" <ceph-devel@vger.kernel.org>
Cc: Jason Dillaman <dillaman@redhat.com>
Subject: Re: About Adding eventfd support for LibRBD
Date: Tue, 07 Jul 2015 20:08:18 -0700	[thread overview]
Message-ID: <559C9422.8010403@redhat.com> (raw)
In-Reply-To: <CACJqLyb5spgWuxAc-rLctp6RapKuWmmdNwg42CbRNOEcxW5XGw@mail.gmail.com>

On 07/07/2015 08:18 AM, Haomai Wang wrote:
> Hi All,
>
> Currently librbd support aio_read/write with specified
> callback(AioCompletion). It would be nice for simple caller logic, but
> it also has some problems:
>
> 1. Performance bottleneck: Create/Free AioCompletion and librbd
> internal finisher thread complete "callback" isn't a *very
> littleweight" job, especially when "callback" need to update some
> status with lock hold
>
> 2. Call logic: Usually like fio rbd engine, caller will maintain some
> status with io and rbd callback isn't enough to finish all the jobs
> related to io. For example, caller need to check each queued io
> stupidly again when rbd callback finished.
>
> So maybe we could add new api which support eventfd, so caller could
> add eventfd to its event loop and batch reap finished io event and
> update status or do more things.
>
> Any feedback is appreciated!

It seems like a good idea to me. I'm not sure how much overhead it
avoids, but letting the callers check status from their own threads
is much nicer in general.

I'd be curious how much overhead the callback + finisher add. If it's
significant, it might make sense to add similar eventfd interfaces
lower in the stack too.

Josh

  reply	other threads:[~2015-07-08  3:08 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-07-07 15:18 About Adding eventfd support for LibRBD Haomai Wang
2015-07-08  3:08 ` Josh Durgin [this message]
2015-07-08  3:46   ` Haomai Wang
2015-07-10  3:16     ` Haomai Wang
2015-07-13 13:52       ` Jason Dillaman
2015-07-13 17:14         ` Haomai Wang
2015-07-13 17:32           ` Jason Dillaman
2015-07-13 18:16             ` Milosz Tanski
2015-07-13 18:39               ` Jason Dillaman
2015-07-13 18:42                 ` Sage Weil
2015-07-13 19:58                   ` Josh Durgin
2015-07-20  5:03                     ` Alexandre DERUMIER
2015-07-13 19:36                 ` Milosz Tanski

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=559C9422.8010403@redhat.com \
    --to=jdurgin@redhat.com \
    --cc=ceph-devel@vger.kernel.org \
    --cc=dillaman@redhat.com \
    --cc=haomaiwang@gmail.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.