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. -- Jens Axboe -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
