On Mon, Jul 13, 2015 at 1:32 PM, Jason Dillaman <dillaman@xxxxxxxxxx> wrote: >> Sorry, I'm not following. Even we have poll_io_events, we need to when >> to call "poll_io_events". >> >> I guess you mean we could notify user's side "fd" in rbd callback. >> Yes, we could do this. But a extra rbd callback could be omitted if we >> embed standard notification methods, we can get performance benefits >> via inline notify and maybe we can reduce internal completion >> structures(maybe?). >> > > Perhaps if you could provide a full example of how you seeing this be used, it would be helpful. Are you proposing to just use eventfd (and its equivalents under other OSs) in-lieu of a mutex/condition variable. I.e. when an AioCompletion finishes, it would add itself to a (potentially lock-free) list of completed AIO ops to be returned by the next "poll_io_events" invocation -- which is signaled via the eventfd mechanism instead of the using a pipe or lock/condition variable. A lock free list (SPSC) + an eventcount to prevent busy waiting is probably the best balance between performance and not busy spinning in the free / full case. But it doesn't provide an easily compassable way of integrating waiting on other events in the application. eventfd is easy to embed in your (e)pool loop or any kind of event library (libev). > -- > To unsubscribe from this list: send the line "unsubscribe ceph-devel" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html -- Milosz Tanski CTO 16 East 34th Street, 15th floor New York, NY 10016 p: 646-253-9055 e: milosz@xxxxxxxxx -- To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
