Andrew Morton <akpm@zip.com.au> wrote:
>I have not yet seen a BIO allocation failure in testing. This
>would indicate that either the BIO pool is too large, or I'm
>running the wrong tests. Either way, I don't think we have
>demonstrated any otherwise-unsolvable problems with BIO allocation.
You need to prove that this can never happen once the
device is initialized, not just that no 2.5 user has reported it
yet.
>What bugs me about your approach is this: I have been gradually
>nudging the kernel's IO paths away from enormously-long per-page
>call paths and per-page locking into the direction of a sequence
>of short little loops, each of which does the same stuff against
>a bunch of pages.
You need to reread the last paragraph of my previous post.
I have added some capitalization to help:
>> I think I would be happy enough with your approach, but, just
>>to eliminate possibilities of memory allocation failure, I think I
>>want to still have some kind of bio_chain, perhaps without the merge
>>hinting, BUT WITH A PARAMETER TO ALLOW FOR ALLOCATING A BIO UP TO THE
>>SIZE OF OLDBIO, like so:
>>
>>struct bio *bio_chain(struct bio *oldbio, int gfp_mask,
>> int nvecs /* <= oldbio->bi_max */);
This would not interfere with your plans try to do things
in n page chunks.
Adam J. Richter __ ______________ 575 Oroville Road
adam@yggdrasil.com \ / Milpitas, California 95035
+1 408 309-6081 | g g d r a s i l United States of America
"Free Software For The Rest Of Us."
-
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 : Sat Jun 15 2002 - 22:00:32 EST