Messages in this thread | | | Date | Fri, 5 Jul 2002 09:38:45 +0200 | From | Jens Axboe <> | Subject | Re: [BUG-2.5.24-BK] DriverFS panics on boot! |
| |
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/
| |