On Tue, May 27 2014 at 3:56pm -0400, Kent Overstreet <kmo@xxxxxxxxxxxxx> wrote: > On Tue, May 27, 2014 at 01:33:06PM -0400, Mike Snitzer wrote: > > On Tue, May 27 2014 at 12:26pm -0400, > > Mikulas Patocka <mpatocka@xxxxxxxxxx> wrote: > > > > > On Tue, 27 May 2014, Jens Axboe wrote: > > > > > > > On 2014-05-27 09:23, Mikulas Patocka wrote: > > > > > > > > > The patch adds bio list flushing to the scheduler just besides plug > > > > > flushsing. > > > > > > > > ... which is exactly why I'm commenting. It'd be great to avoid yet one more > > > > scheduler hook for this sort of thing. > > > > > > > > -- > > > > Jens Axboe > > > > > > One could create something like schedule notifier chain, but I'm not sure > > > if it is worth the complexity because of just two users. If more users > > > come in the future, it could be generalized. > > > > It could be that Jens is suggesting updating blk_needs_flush_plug() and > > blk_schedule_flush_plug() to be bio_list aware too (rather than train > > sched_submit_work() from this new bio_list)? > > > > Somewhat awkward, but _could_ be made to work. > > No... > > I started on this ages and ages ago, but the patches were nowhere near ready to > go out. > > What I'd do is rework the existing blk_plug to work in terms of bios, not > requests. This is a fair amount of work, and then make_request_fn() needs to be > able to take multiple bios at a time, but IIRC there were other simplifications > that fell out of this and this also means bio based drivers can take advantage > of plugging/batching. > > Once this is done, you just... replace the bio list in generic_make_request() > with a plug. Boom, done. > > (oh, and to avoid blowing the stack the scheduler/plug callback or whatever > needs to check the current stack usage and punt off to a per request_queue > workqueue, but that's easy enough). Re-reading your response since this bug is still lingering; and Mikulas' patch _still_ fixes the deadlock.. you're suggesting all of the above just to avoid an extra conditional scheduler callout.. Could be what you're proposing is "the one true way forward" but I'm not touching it at this point. -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
