Re: [PATCH 2/7] move setting of object->type to alloc_* functions

From: Jeff King <peff@peff.net>
Date: Jul 14, 2014, 05:57 UTC
Message-ID: <20140714055727.GA5593@sigill.intra.peff.net>
In-Reply-To: <53C2DDB7.2070708@ramsay1.demon.co.uk>

On Sun, Jul 13, 2014 at 08:27:51PM +0100, Ramsay Jones wrote:

Show 11 quoted lines

> > 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).

Show 5 quoted lines

> 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