On Thu, Feb 02, 2012 at 03:51:03PM -0500, Zach Brown wrote: > > Well, for that one blocking case in the submission path. > > I certainly understand the desire to just make things less painful in > this case, but I do wonder if the long-term win is to sink resources > into trying to get threads executings async op so that the code paths > don't have to be butchered into state machines around each potential > blocking op. I only intend to do this for reads and non-allocating writes; in those cases, it's actually pretty easy. And if everything is already in cache, it's a lot easier to make things fast and not require diving into workqueue or some other kernel thread. My concern with just stuffing every single io_submit into a kernel thread is the overhead involved, especially if there is a high rate of AIO submission (think high-speed PCIe-attached flash). Either you will end up blocking waiting for a kernel thread to be available, or you will burn a huge amount of kernel memory for the thread stacks if nothing else. - Ted -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
