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/