Hello, On Mon, Mar 07, 2011 at 02:50:28PM -0500, Jeff Moyer wrote: > > 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. Yeah, IDE is the only one which actually depends on it. At the time I thought more drivers would use the sleeping context but that didn't happen (yet). That said, I think it's generally a good idea to guarantee context on the issue path (the request_lock requirement makes it quite ugly to use but that's a separate issue). It makes things much easier - e.g. we can use mempool and friends for forward progress guarantee instead of doing explicit retrying which also can hide deadlocks quite effectively. > 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? I don't think it matters. First of all, the overhead itself isn't that big to begin with. More importantly, the flush optimization is not about squeezing out the last cpu cycles out of the existing path. It's about consolidating similar operations and thus increasing scalability when a storm of fsync's are issued in parallel likely with a lot of other IOs. The kicking path won't be used at all on busy queues (queue won't be empty). So, I don't think there's anything to worry about here. Thanks. -- tejun -- 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
