Re: [RESEND] [PATCH] readahead:add blk_run_backing_dev

[Vladislav Bolkhovitin]

Ronald Moesbergen, on 08/03/2009 01:15 PM wrote:
> 2009/7/31 Vladislav Bolkhovitin <vst@xxxxxxxx>:
> > OK, as I expected, on the SCST level everything is clear and the forced
> > ordering change didn't change anything.
> >
> > But still, a single read stream must be the fastest from single thread.
> > Otherwise, there's something wrong somewhere in the I/O path: block layer,
> > RA, I/O scheduler. And, apparently, this is what we have and should find out
> > the cause.
> >
> > Can you check if noop on the target and/or initiator makes any difference?
> > Case 5 with 1 and 2 threads will be sufficient.
>
> That doesn't seem to help:
>
> client kernel: 2.6.26-15lenny3 (debian)
> server kernel: 2.6.29.5 with readahead-context, blk_run_backing_dev
> and io_context, forced_order
>
> With one IO thread:
> 5) client: default, server: default (server noop, client noop)
> blocksize       R        R        R   R(avg,    R(std        R
>   (bytes)     (s)      (s)      (s)    MB/s)   ,MB/s)   (IOPS)
>  67108864  17.612   21.113   21.355   51.532    4.680    0.805
>  33554432  18.329   18.523   19.049   54.969    0.891    1.718
>  16777216  18.497   18.219   17.042   57.217    2.059    3.576
>
> With two threads:
> 5) client: default, server: default (server noop, client noop)
> blocksize       R        R        R   R(avg,    R(std        R
>   (bytes)     (s)      (s)      (s)    MB/s)   ,MB/s)   (IOPS)
>  67108864  17.436   18.376   20.493   54.807    3.634    0.856
>  33554432  17.466   16.980   18.261   58.337    1.740    1.823
>  16777216  18.222   17.567   18.077   57.045    0.901    3.565

And with client cfq, server noop?

> Ronald.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/