Jens Axboe wrote: > On Wed, Dec 20 2006, Kiyoshi Ueda wrote: >> Hi Jens, >> >> On Wed, 20 Dec 2006 19:49:17 +0100, Jens Axboe <jens.axboe@xxxxxxxxxx> wrote: >>>>> Big NACK on this - it's not only really ugly, it's also buggy to pass >>>>> interrupt flags as function arguments. As you also mention in the 0/1 >>>>> mail, this also breaks CFQ. >>>>> >>>>> Why do you need in-interrupt request allocation? >>>> >>>> Because I'd like to use blk_get_request() in q->request_fn() >>>> which can be called from interrupt context like below: >>>> scsi_io_completion -> scsi_end_request -> scsi_next_command >>>> -> scsi_run_queue -> blk_run_queue -> q->request_fn >>>> >>>> Generally, device-mapper (dm) clones an original I/O and dispatches >>>> the clones to underlying destination devices. >>>> In the request-based dm patch, the clone creation and the dispatch >>>> are done in q->request_fn(). To create the clone, blk_get_request() >>>> is used to get a request from underlying destination device's queue. >>>> By doing that in q->request_fn(), dm can deal with struct request >>>> after bios are merged by __make_request(). >>>> >>>> Do you think creating another function like blk_get_request_nowait() >>>> is acceptable? >>>> Or request should not be allocated in q->request_fn() anyway? >>> You should not be allocating requests from that path, for a number of >>> reasons. >> Could I hear the reasons for my further work if possible? >> Because of breaking current CFQ? And is there any reason? > > Mainly I just don't like the design, there are better ways to achieve > what you need. The block layer has certain assumptions on the context > from which rq allocation happens, and this breaks it. As I also > mentioned, you cannot pass flags around as arguments. So the patch is > even broken as-is. > I was thinking that since this was going to be hooked into dm which has the make_request hook in code, could we just allocate the cloned request when from dm's make_request callout. The dm queue would call __make_request, and if it detected that the bio started a new request it would just allocate a second request which would be used as a clone or maybe the block layer could allocate the clone request for us. On the request_fn callout side, DM could then setup the cloned rq based on the original fields and pass it down to the dm-multipath request_fn. The dm-mutlipath request_fn then just decides which path to use based on the path-selector modules and then we send it off. -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
