[dm-devel] Re: 1st of 2 patches for dm_emc.c and dm-multipath hardware handler interface

Mike Christie michaelc at cs.wisc.edu
Thu Oct 5 18:09:41 UTC 2006


Edward Goggin wrote:
> On Friday, September 08, 2006 1:21 PM, Mike Christie wrote
>> Edward Goggin wrote:
>>> +
>>> +	rq->buffer = rq->data = h->buffer;
>>> +	rq->data_len = len;
>>> +	rq->bio = rq->biotail = NULL;
>>>  
>> I think I only suggested that you use the block layer map functions in
>> the previous review. Now I will say, use them and fix the core code to
>> not allocate memory or use a mempool since it will also fix the path
>> testers at the same time :) The reason is that the scsi layer 
>> is trying
>> to make every thing run with scatterlists. In 2.6.18, every place is
>> converted (they should be at least), so you should not be 
>> adding another
>> place where we send down a data buffer like this.
>>
> 
> Mike, sorry for the long delay.

No problem.

> 
> I certainly can (and have tried already before submitting the patch
> as is) change the code to call blk_rq_map_kern instead of using the
> code sequence you have identified above.  As you cite, I was trying
> to avoid memory/mempool allocation (for a bio) while servicing the io.
> 
> As far as fixing the code to not allocate memory or use a mempool,
> let me know if the description below is what you have in mind?
> 
> A slightly modified version of __bio_map_kern
> (and modified versions of its callers like blk_rq_map_kern)
> which would accept a ptr to bio as a parameter instead of
> allocating one.  Any kernel resident code like a dm-multipath
> hardware handler could obtain a bio beforehand from a distinct
> bio_set (bio mempool).  In the dm-multipath hardware handler
> case, a single bio_set could be associated with each target
> path (struct path).

So do we need bioset per path or even per module here?

Is the problem we are trying to solve:
1. we would allocate a bio from the same bioset as the layer above dm so
if that bioset is depleted we cannot perform REQ_BLOCK_PC commands (or
whatever they are called in 2.6.19.
2. we need some reserve bio so we can always allocate a bio.

If so could we just make a bio set for all blk pc commands and then for
GFP_NOIO do a wait similar to what ll_rw_blk.c does for requests. See
the attached patch for details. But this approach would solve the
problem for the path testers and hw handlers and sg.c and st.c at the
same time. The problem I see with it is that it is not fair and it is
possible that someone could wait forever, but I am not sure if that is
very realistic and I am not sure if that is a bad enough problem to
justify adding biosets for every driver.

But for all this you should ask/cc Jens Axboe. He is the block layer
maintainer.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: out.patch
Type: text/x-patch
Size: 1827 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/dm-devel/attachments/20061005/392beda5/attachment.bin>


More information about the dm-devel mailing list