On Thu, Jul 04 2002, Andre Hedrick wrote:
> On Fri, 5 Jul 2002, Jens Axboe wrote:
>
> > On Thu, Jul 04 2002, Andre Hedrick wrote:
> > > 1) 8K writes and 64K (or larger) reads.
> >
> > I've heard this before, but noone seems to have tested it yet. You know,
> > this is a couple of lines of change in ll_rw_blk.c and blkdev.h to
> > support this. Any reason you haven't done that, benched, and submitted
> > something to that effect? I'll even walk you through the 2.5 changes
> > needed to do this:
>
>
> [root@localhost mnt2]# bonnie -s 256
[snip bonnie results]
These mean nothing to me -- what are they, the base line or the changed
kernel? Or none of the above?!
> Using the hardware to help us and by working with it it, once can
> basically boost the write and slash the cpu usage.
You need to add some context to that statement.
> > > 2) ONE maybe TWO passes on elevator operations.
> >
> > Explain.
>
> On writes restrict which are small the ordering is almost instant.
> Specifically ONE maybe TWO passes will sort.
>
> Reads may need more as we optimize best on big reads.
So you are saying that writes don't need to be reordered as much,
because the drive typically does that? I guess that will always be true
with write back caching, I doubt that holds for write through.
And I don't quite follow the number of passes you compare, passes of
what? Insert and merge are a single pass per request, tops.
-- Jens Axboe- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sun Jul 07 2002 - 22:00:14 EST