Jens Axboe <axboe@xxxxxxxxx> writes: > On 2011-03-07 20:39, Jeff Moyer wrote: >>>> I think the real issue may just be that the ide driver is blocking in >>>> its request function. What have I missed? >>> >>> So the only case where the request_fn is called and you cannot block, is >>> if you call it from your completion function. Any other invocation >>> should be from process context. As long as you remember to drop the >>> queue lock and re-enable interrupts, it should work. It's not great >>> style and I would not recommend it for a performance environment, but it >>> should work. >> >> So are you agreeing with me or disagreeing? ;-) It sounds to me like >> you're saying that the ide driver should be able to cope with being >> called from softirq context. > > I'm just stating how it should work :-) > > But yes, it sounds like IDE is violating this rule and that's why it was > broken. Even with that, having explicit control of the queue running > does make sense. Well, I wonder if it makes sense *in this case*. With all of the work going into optimizing the flushing, is deferring work to kblockd really the best idea? Tejun, do you know if it has any measurable impact? Cheers, Jeff -- To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
