Hello, Jens. Jens Axboe wrote: >> Almost all operations are per-cpu so cache lines shouldn't bounce too >> much. The only part I worry about is the part which checks whether a >> work is currently executing on the current cpu which currently is >> implemeted as a hash table. The hash table is only 16 pointers long >> and will be mostly empty so hopefully it doesn't add any significant >> overhead. > > OK, we'll let time and experimentation be the judge. Yeap. >>> 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. -- 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
