On Sun, Jul 13, 2014 at 08:27:51PM +0100, Ramsay Jones wrote: > > Thinking on this more, writing out the definitions is the only sane > > thing to do here, now that alloc_commit_node does not use the macro. > > Otherwise you are inviting people to modify the macro, but fail to > > notice that the commit allocator also needs updating. > > Hmm, well I could argue that using the macro for all allocators, apart > from alloc_commit_node(), clearly shows which allocator is the odd-man > out (and conversely, that all others are the same)! :-P > > No, I don't think this is a telling advantage; I don't think it makes > that much difference. (six of one, half-a-dozen of the other). Yeah, I agree with your final statement in parentheses. I am OK with it either way (but I have a slight preference for what I posted). > I was slightly concerned, when reading through this new series, that the > alloc_node() function may no longer be inlined in the new allocators. > However, I have just tested on Linux (only using gcc this time), and it > was just fine. I will test the new series on the above systems later > (probably tomorrow) but don't expect to find any problems. That should not be due to my patches (which are just expanding macros), but rather to your 1/8, right? I do not know that it matters that much anyway. Yes, we allocate a lot of objects in some workloads. But I think it is not so tight a loop that the extra function call is going to kill us (and we tend to _read_ the allocated objects much more than we allocate them). > > Here's a re-roll. The interesting bit is the addition of the second > > patch (but the rest needed to be rebased on top). > > Yep, this looks good. Thanks! Thanks for reviewing, as usual. -Peff -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html