Messages in this thread | | | From | "Ph. Marek" <> | Subject | Re: [RFC] Stacking bio support | Date | Tue, 11 Mar 2008 12:33:21 +0100 |
| |
Hello Daniel!
On Dienstag, 11. März 2008, Daniel Phillips wrote: > 3: bio.stack-2.6.23.12 > > This adds an internal stack to each struct bio and introduces two new > bio operations: > > data = bio_push(bio, worksize, endio); > data = bio_pop(bio); > > The first is used before submitting a bio and the second is used in the > endio handler, which gives the driver a nice way to share context > between the two events. If the requested amount stack space is not > available in the bio, the bio stack is automatically extended. ... > (I learned from Andreas Dilger last month at FAST that Lustre already > implements a mechanism along these lines.) Win32 has IRP stacks, which do mostly the same AFAIU. http://msdn2.microsoft.com/en-us/library/ms796144.aspx
How do you handle the reallocation? - If you don't do it (but rely on the fact that the initial allocation is enough), you might end up with NO_MORE_IRP_STACK_LOCATIONS http://msdn2.microsoft.com/en-us/library/ms793675.aspx - If you do reallocate, the allocations have to register themselves in the emergency pool (see the current thread about swapping over NFS)
I don't say that it's impossible ... just that some "interesting" things will await you.
> Currently the stack size in the bio is set to zero and is always > extended on the first bio_push. An upcoming revision will add a > mechanism for a block driver to specify the initial amount of stack > space it knows will always be needed. Some time further in the future, > a mechanism for discovering the stack requirements of several block > devices in a stack may be added, so that a typical bio submission is > able to traverse the entire stack with only a single bio allocation. That's different from the Win32 way AFAIK - there it's defined that every layer *has* to use its own stack location. (But it's been some time since I needed that, so I might be wrong.)
But I sure hope you succeed!
Regards,
Phil -- 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/
| |