Jens suparna hello
I have managed to understand why io_submit is sometimes very slow.
It is because the device is plugged once too many io's are being sent.
I have conducted a simple test with nr_request to default value of 128
and and 256.
and it proved to be correct.
I would truely appreciate your comment on this.
--
Raz
On Fri, Dec 01 2006, Raz Ben-Jehuda(caro) wrote:
> Jens suparna hello
>
> I have managed to understand why io_submit is sometimes very slow.
> It is because the device is plugged once too many io's are being sent.
> I have conducted a simple test with nr_request to default value of 128
> and and 256.
> and it proved to be correct.
I don't understand your email. The device is plugged when it is empty,
not when it has emptied the request list.
> I would truely appreciate your comment on this.
On what? :-)
If it's no blocking and returning EAGAIN instead, then I agree this is
what should eventually happen. Right now nobody is working on that
afaik, so it's not something that will hit the next kernel.
--
Jens Axboe
On 12/1/06, Jens Axboe <[email protected]> wrote:
> On Fri, Dec 01 2006, Raz Ben-Jehuda(caro) wrote:
> > Jens suparna hello
> >
> > I have managed to understand why io_submit is sometimes very slow.
> > It is because the device is plugged once too many io's are being sent.
> > I have conducted a simple test with nr_request to default value of 128
> > and and 256.
> > and it proved to be correct.
>
> I don't understand your email. The device is plugged when it is empty,
> not when it has emptied the request list.
first , i am not top posting you.
I made a mistake and associated plugging with a full queue.
> > I would truely appreciate your comment on this.
>
> On what? :-)
>
> If it's no blocking and returning EAGAIN instead, then I agree this is
> what should eventually happen.
Who returns EGAIN to whom ? I am not sure i understand what you mean here.
> Right now nobody is working on that
> afaik, so it's not something that will hit the next kernel.
thank you
raz
> --
> Jens Axboe
>
>
--
Raz
Raz Ben-Jehuda(caro) wrote:
> Who returns EGAIN to whom ? I am not sure i understand what you mean
> here.
If the queue is full then io_sumbit() should return EAGAIN or some other
error to indicate that the queue is full, but right now it just blocks
instead.
On 12/4/06, Phillip Susi <[email protected]> wrote:
> Raz Ben-Jehuda(caro) wrote:
> > Who returns EGAIN to whom ? I am not sure i understand what you mean
> > here.
>
> If the queue is full then io_sumbit() should return EAGAIN or some other
> error to indicate that the queue is full, but right now it just blocks
> instead.
>
thanks Phiilip
But... hmmm ... should'nt an asynchronous operation act as
"send and forget" . isn't "queue full" a problem that aio must at
least try and handle before returning to the user ?
--
Raz
Raz Ben-Jehuda(caro) wrote:
> thanks Phiilip
> But... hmmm ... should'nt an asynchronous operation act as
> "send and forget" . isn't "queue full" a problem that aio must at
> least try and handle before returning to the user ?
It is handling it; by blocking until the queue is not full. A better
way of handling it would be to return in such a way that the caller
knows the queue is full and needs to wait before it can submit more
requests, possibly doing some computation or submitting requests to
other devices in the mean time.