Alan Cox wrote:
>
> > But this gets you lowest common denominator sizes for the whole
> > volume, which is basically the buffer head approach, chop all I/O up
> > into a chunk size we know will always work. Any sort of nasty boundary
> > condition at one spot in a volume means the whole thing is crippled
> > down to that level. It then becomes a black magic art to configure a
> > volume which is not restricted to a small request size.
>
> Its still cheaper to merge bio chains than split them. The VM issues with
> splitting them are not nice at all since you may need to split a bio to
> write out a page and it may be the last page
How about reserving a small memory pool for splitting when normal
memory allocation fails?
I know we want a clean kernel,
so this mechanism would be implemented in those drivers that
actually need it. I.e. raid0/5 would keep a
emergency split buffer around for bio's bigger than the
stripe size, devices with all sorts of odd requirement could do the
same.
This might look like duplication, but isn't really as the different
devices
might need different splitting anyway. I.e. RAID want to
split into stripe-sized chunks but no smaller, an odd device might
need something different. The disk concatenation in md would
only want to split when you actually hit a boundary.
Also, letting each driver handle the special cases itself
works when someone makes raid-0 on top
of weird adapters.
A kernel with just plain disk drivers wouldn't need
and wouldn't have such mechanisms either.
Helge Hafting
-
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 : Tue Apr 30 2002 - 22:00:09 EST