[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [dm-devel] New -udm?



Mike Christie wrote:
Lars Marowsky-Bree wrote:

On 2005-04-10T18:14:44, Dave Olien <dmo osdl org> wrote:


You're correct.  I'll rewrite it on Thursday this week.
I'll use the same methods Lars used in the dm-emc.c



Note that dm-emc.c also would need to pre-allocate it's requests, but doesn't right now :/

Pre-allocating the requests sucks: Either we pre-allocate for _every_
path we might potentially need to send the request down on, or fix up
the request for the path we sent it down on (which would require us to
use internal knowledge about the req structs we're not supposed to
have).


what is wrong with what you have now where you utilize the queue/path's mempool by doing a blk_get_request with GFP_WAIT? Is that "fix up the request..." comment meaning that you do not like to access the request structure for that code, or was it meaning that you have one request that is shared across paths and it needs to be cleaned up for reuse.

I think the hw_handlers setting up the requests is not so fun. Maybe the block layer scsi_ioctl code could be reworked a little so that it could set some of that up for us since it is very similar.

it is similar, but where the sgio paths allocated with GFP_KERNEL I used atomics. For the page allocation (which is way to large for the lsi command) I originally just preallocated a page but that seemed to wasteful. All I really needed to preallocate was my mode page struct and done a virt_to_page to get the page pointer to pass to bio_add_page (I wasn't sure if I could do that at the time), I guess? Since I ended up failing over at the controller level the preallocation would not even have to be per path so it would not have been that much waste.



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]