On 11/18/2014 07:55 PM, Tejun Heo wrote: > Hello, > > On Tue, Nov 18, 2014 at 05:19:18PM +0800, Lai Jiangshan wrote: >> Is it too ugly? > > What is "it"? The whole thing? percpu preloading? I'm just gonna > continue assuming that you're talking about preloading. If you think > it's ugly, please go ahead and explain why you think it is. Sorry. "it" = "preload" > > It's almost impossible to respond to your "review". It's not clear > what your subject matter or opinion on it is. Might as well just bang > on the keyboard randomly. When reviewing (or communicating in > general), please try to properly form and elaborate your points. > Other people can't know what's going on in your brain and have to > speculate what you could have meant. > > This implementation of preloading an evolution of a design pattern > which, IIRC, first started with the radix tree. The non-failing > aspect was introduced while the pattern was being applied to idr. I > think it's one of the better ways to implement preloading. > >> What will be the most important result it achieve? > > This is the same as other preloading. It allows pulling allocation > out of critical section so that it can be done with more generous > allocation mask (ie. GFP_KERNEL instead of GPF_NOWAIT). It's a common > pattern found in data structures which may allocate memory internally > such as radix tree or idr. To me, this does explain why it is ugly. The "preload" trick separates one operation (the memory-allocation) into 3 steps(functions) and creates a special critical region which is preempt-disabled, which is non-workable-when-nested, the later drawback also means preload can't work in softirqs/irqs... I can't argue for existing code. I accept the prelaod in radix tree and idr. And they are important data structures. (I mean they achieve important result) so tricks or some thing applied to them seems some kinds of acceptable. Even in idr, idr_alloc() includes two operations, id-allocation (includes memroy-allocation) and id-resource-association. These two operations can be separated into 2 functions without any "preload". (this separation is different from the one in "preload", this possible separation makes one function only do one thing, "preload"-approach uses 3 functions together to do one thing or 2 things.) Thanks. Lai -- 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
