On Fri, Aug 28 2009, Tejun Heo wrote: > >>> Care to post it? I know you don't think it's perfect yet, but it would > >>> make a lot more sense to throw effort into this rather than waste time > >>> on partial solutions. > >> I have this printed out code with full of red markings from proof > >> reading and flush implementation is mostly broken. Please give me a > >> couple of days. I'll post a rough unsplit version which at least > >> compiles with the planned changes applied by the end of the week. :-) > > > > Alright, fair enough. > > > > One question - do the 'exposed' workqueues (the ones that drivers > > allocate/create) sitting in front of the global cpu queue allow more > > than one thread per cpu, or is that property retained for the global cpu > > queue (where it is a necessity)? > > The exposed workqueues basically just play the gateway and don't have > threads associated with it, well, at least not the normal ones. It > may have single dedicated thread which usually isn't used but only > gets summoned when a queue stall is detected (new thread needs to be > created but blocks on allocation kind of situation). So, only the > global cpu queue has normal workers and there are multiple per cpu and > they're shared by all exported workqueues. Thanks for the clarification, it answers the question on what level of functionality is observed by the exported workqueues. Sounds good! -- Jens Axboe -- 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
