Hi Fam, On Thu, Nov 06, 2014 at 08:44:36PM +0800, Fam Zheng wrote: > In this case, it is basically a polling. Let's not involve timer at all > because that would hurt performance for application event loops. > > In an arbitrary test I've done, io_getevents syscall elapsed time > reduces from 50000+ nanoseconds to a few hundereds. This looks quite reasonable. I've applied this to my aio-next tree. -ben > Signed-off-by: Fam Zheng <famz@xxxxxxxxxx> > --- > fs/aio.c | 8 ++++++-- > 1 file changed, 6 insertions(+), 2 deletions(-) > > diff --git a/fs/aio.c b/fs/aio.c > index 84a7510..7c0b561 100644 > --- a/fs/aio.c > +++ b/fs/aio.c > @@ -1221,8 +1221,12 @@ static long read_events(struct kioctx *ctx, long min_nr, long nr, > * the ringbuffer empty. So in practice we should be ok, but it's > * something to be aware of when touching this code. > */ > - wait_event_interruptible_hrtimeout(ctx->wait, > - aio_read_events(ctx, min_nr, nr, event, &ret), until); > + if (until.tv64 == 0) > + aio_read_events(ctx, min_nr, nr, event, &ret); > + else > + wait_event_interruptible_hrtimeout(ctx->wait, > + aio_read_events(ctx, min_nr, nr, event, &ret), > + until); > > if (!ret && signal_pending(current)) > ret = -EINTR; > -- > 1.9.3 -- "Thought is the essence of where you are now." -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
