Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754098AbbBZRQy (ORCPT ); Thu, 26 Feb 2015 12:16:54 -0500 Received: from bombadil.infradead.org ([198.137.202.9]:41008 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752169AbbBZRQx (ORCPT ); Thu, 26 Feb 2015 12:16:53 -0500 Date: Thu, 26 Feb 2015 18:16:26 +0100 From: Peter Zijlstra To: Mathieu Desnoyers Cc: Andi Kleen , Andi Kleen , x86@kernel.org, linux-kernel@vger.kernel.org, oleg@redhat.com, paulmck@linux.vnet.ibm.com, rusty@rustcorp.com.au, mingo@kernel.org Subject: Re: [RFC][PATCH] module: Optimize __module_address() using a latched RB-tree Message-ID: <20150226171626.GW21418@twins.programming.kicks-ass.net> References: <1424482737-958-1-git-send-email-andi@firstfloor.org> <20150223170436.GC5029@twins.programming.kicks-ass.net> <20150223174340.GD27767@tassilo.jf.intel.com> <20150226114309.GR21418@twins.programming.kicks-ass.net> <2127583772.183982.1424966563927.JavaMail.zimbra@efficios.com> <20150226164356.GU21418@twins.programming.kicks-ass.net> <2065867235.184322.1424969735591.JavaMail.zimbra@efficios.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2065867235.184322.1424969735591.JavaMail.zimbra@efficios.com> User-Agent: Mutt/1.5.21 (2012-12-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2215 Lines: 65 On Thu, Feb 26, 2015 at 04:55:35PM +0000, Mathieu Desnoyers wrote: > > Dunno, it seemed like a good a place as any. > > My personal coding-style is to put all definitions > at the top of C files, but I don't know if it's within > the kernel coding style guide lines or just something > I'm personally used to. I have no strong opinion here. So I had all the data structure definition in the C file as well to keep them private, and then you get into the situation where you can't put it at the top anyhow. I further wanted to keep the entire mod_tree stuff together so it can be easily read. I suppose I can move it to the top of that section, but the reason I had it there is that it didn't need to exist before that. > > @@ -269,8 +275,15 @@ struct module { > > /* Startup function. */ > > int (*init)(void); > > > > + /* > > + * If this is non-NULL, vfree after init() returns > > + * > > + * cacheline align here, such that: > > + * module_init, module_core, init_size, core_size and > > + * tree_node[0] > > + * are on the same cacheline. > > Fat-fingered newline ? ;) I made it: /* * If this is non-NULL, vfree after init() returns. * * Cacheline align here, such that: * module_init, module_core, init_size, core_size, * init_text_size, core_text_size and tree_node[0] * are on the same cacheline. */ To be consistent with the other comment. > > + */ > > + void *module_init ____cacheline_aligned; > > > > /* Here is the actual code + data, vfree'd on unload. */ > > void *module_core; > > @@ -281,6 +294,8 @@ struct module { > > /* The size of the executable code in each section. */ > > unsigned int init_text_size, core_text_size; > > > > + struct module_node tree_node[4]; > > 4 -> nr_module_addr_latch Yeah, I dunno, that means moving that enum to the header file, I kinda liked having it all together in the C file. What Rusty want though. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/