Calling Linux io_getevents without blocking

Calling Linux io_getevents without blocking

[Daniel Ehrenberg]

Hi,

I'm trying to recreate a workload which would call the io_getevents
function in Linux libaio without blocking, spinning until the result
comes up. There are two ways to make io_getevents return immediately
if there are no results: pass in a timeout of 0, or pass min_nr=0. (Of
course, this non-blocking way of invoking io_getevents wouldn't be
used by the cleanup routines, only during the main loop). I can't
figure out what the proper way to do this is. I don't see an option
that would allow this. I thought iodepth_batch_complete=0 would make
the min_nr be 0, but it seems that the minimum number in practice is
1, as lines 555-556 establish. It looks like if
iodepth_batch_complete=0, then full might be false and min_nr might
not be set to 1, but this often isn't the case in my testing. I don't
see how to set a different timeout from the default, which seems to be
NULL.

Am I missing something? What would be the proper way of allowing this
setting in a way that doesn't break other engines? One way I hacked up
is to make a new boolean option which sets min_events to 0 right after
line 556 if enabled (and similarly for the do_io main loop). Is there
a better way to do it? Otherwise, would you accept a patch that
implements this?

Thanks,
Dan

Re: Calling Linux io_getevents without blocking

[Jens Axboe]

On 2011-07-14 04:49, Daniel Ehrenberg wrote:
> Hi,
> 
> I'm trying to recreate a workload which would call the io_getevents
> function in Linux libaio without blocking, spinning until the result
> comes up. There are two ways to make io_getevents return immediately
> if there are no results: pass in a timeout of 0, or pass min_nr=0. (Of
> course, this non-blocking way of invoking io_getevents wouldn't be
> used by the cleanup routines, only during the main loop). I can't
> figure out what the proper way to do this is. I don't see an option
> that would allow this. I thought iodepth_batch_complete=0 would make
> the min_nr be 0, but it seems that the minimum number in practice is
> 1, as lines 555-556 establish. It looks like if
> iodepth_batch_complete=0, then full might be false and min_nr might
> not be set to 1, but this often isn't the case in my testing. I don't
> see how to set a different timeout from the default, which seems to be
> NULL.
> 
> Am I missing something? What would be the proper way of allowing this
> setting in a way that doesn't break other engines? One way I hacked up
> is to make a new boolean option which sets min_events to 0 right after
> line 556 if enabled (and similarly for the do_io main loop). Is there
> a better way to do it? Otherwise, would you accept a patch that
> implements this?

I'd be fine with allowing the nonblocking/spinning variant if set
explicitly. My only worry is people doing this by accident. But if
iodepth_batch_complete was explicitly set to 0, then we should honor
that. So I'll happily take a patch to modify that.

-- 
Jens Axboe