On Sun, 2009-05-03 at 15:20 -0400, Jeff Garzik wrote:[tangent...]
Does make you wonder if a ->init_rq_fn() would be helpful, one that could perform gfp_t allocations rather than GFP_ATOMIC? The idea being to call ->init_rq_fn() almost immediately after creation of struct request, by the struct request creator.
Isn't that what the current prep_fn actually is?
It's hard to see how ... prep_rq_fn is already called pretty early ...
almost as soon as the elevator has decided to spit out the request
The creator of struct request generally has more freedom to sleep, and it seems logical to give low-level drivers a "fill in LLD-specific info" hook BEFORE the request is ever added to a request_queue.
Unfortunately it's not really possible to find a sleeping context in
there: The elevators have to operate from the current
elv_next_request() context, which, in most drivers can either be user or
interrupt.
The ideal for REQ_TYPE_DISCARD seems to be to force a page allocation
tied to a bio when it's issued at the top. That way everyone has enough
memory when it comes down the stack (both extents and WRITE SAME sector
will fit into a page ... although only just for WRITE SAME on 4k
sectors).