public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
* linux io_submit syscall duration
@ 2006-11-15  7:39 Raz Ben-Jehuda(caro)
  2006-11-15  7:47 ` Jens Axboe
  0 siblings, 1 reply; 3+ messages in thread
From: Raz Ben-Jehuda(caro) @ 2006-11-15  7:39 UTC (permalink / raw)
  To: linux-aio, Linux Kernel; +Cc: bcrl, zach.brown

Bnejamin hello.

My name is raz and i have encountered a problem with  io_submit.
The maximum duration of a single io_submit operation when
heavily stressing the system with large number of big (1MB) ios,
reaches several hundereds ms.

I have been profiling it and it seems that the problem is the
file->f_op->aio_read operation,
a call that is made in fs/aio.c when coming from:
 sys_io_submit -->
   io_submit_one -->
	  aio_run_iocb -->
   		 *retry


The test is initiating several hundered 1MB IOs over a single block device.

I understand that the assumption made was aio_read is asynchronous and no
delay will occure, but isn't possible to do it in the workqueue context ?

would appreciate your help.
thank you

raz

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: linux io_submit syscall duration
  2006-11-15  7:39 linux io_submit syscall duration Raz Ben-Jehuda(caro)
@ 2006-11-15  7:47 ` Jens Axboe
       [not found]   ` <5d96567b0611150143n1a7cc16dgea39fba748a2de7f@mail.gmail.com>
  0 siblings, 1 reply; 3+ messages in thread
From: Jens Axboe @ 2006-11-15  7:47 UTC (permalink / raw)
  To: Raz Ben-Jehuda(caro); +Cc: linux-aio, Linux Kernel, bcrl, zach.brown

On Wed, Nov 15 2006, Raz Ben-Jehuda(caro) wrote:
> Bnejamin hello.
> 
> My name is raz and i have encountered a problem with  io_submit.
> The maximum duration of a single io_submit operation when
> heavily stressing the system with large number of big (1MB) ios,
> reaches several hundereds ms.
> 
> I have been profiling it and it seems that the problem is the
> file->f_op->aio_read operation,
> a call that is made in fs/aio.c when coming from:
> sys_io_submit -->
>   io_submit_one -->
> 	  aio_run_iocb -->
>   		 *retry
> 
> 
> The test is initiating several hundered 1MB IOs over a single block device.
> 
> I understand that the assumption made was aio_read is asynchronous and no
> delay will occure, but isn't possible to do it in the workqueue context ?

This was discussed no more than a week ago on this list, please search the
archives for the thread.

-- 
Jens Axboe


^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: linux io_submit syscall duration
       [not found]   ` <5d96567b0611150143n1a7cc16dgea39fba748a2de7f@mail.gmail.com>
@ 2006-11-15  9:47     ` Jens Axboe
  0 siblings, 0 replies; 3+ messages in thread
From: Jens Axboe @ 2006-11-15  9:47 UTC (permalink / raw)
  To: Raz Ben-Jehuda(caro); +Cc: inux-aio, linux-kernel, bcrl, zach.brown


(don't top post and don't drop the cc list!)

On Wed, Nov 15 2006, Raz Ben-Jehuda(caro) wrote:
> first thank you from your quick reply.
> 
> I looked and what I found is :
> "io_submit() taking a long time to return ?" from 2006-07-14.

Subject is "async I/O seems to be blocking on 2.6.15" and the posting is
from 2006-11-3. I said about a week ago, not 4 months.

> 1.  It is NOT the first IO. already took care for that in my test.

That was a different problem.

> 2.  The test uses block device and does not walk through a file system.

So would not apply.

> 3.  Taking a look at the code, it seems that the main problem is the fact
>     that in io_submit_one all the pending requests are being rerun.
> 
>    io_submit_one()
>   {
>    ...
>        if (!list_empty(&ctx->run_list)) {
>                /* drain the run list */
>              while (__aio_run_iocbs(ctx))
>                      ;
>      }
>   ...
>   }
> 
>  This code was put in remarks.
> the second is in:
>  aio_run_iocb()
>   ...
>    current->io_wait = &iocb->ki_wait;
>    if ( iocb->ki_retried >  1)
>        ret = retry(iocb);
>    else{
>        ret = -EIOCBRETRY;
>        kiocbSetKicked(iocb);
>    }
>     current->io_wait = NULL;
>  ....
> 
>  With these fixes io_submit delay reduced to zero ms.
> 
> I would appreciate your review on these fixes.

Post a patch so it can be reviewed.

-- 
Jens Axboe


^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2006-11-15  9:48 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2006-11-15  7:39 linux io_submit syscall duration Raz Ben-Jehuda(caro)
2006-11-15  7:47 ` Jens Axboe
     [not found]   ` <5d96567b0611150143n1a7cc16dgea39fba748a2de7f@mail.gmail.com>
2006-11-15  9:47     ` Jens Axboe

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox