From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751914AbdJBSw1 (ORCPT ); Mon, 2 Oct 2017 14:52:27 -0400 Received: from Galois.linutronix.de ([146.0.238.70]:50534 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751236AbdJBSw0 (ORCPT ); Mon, 2 Oct 2017 14:52:26 -0400 Date: Mon, 2 Oct 2017 20:52:23 +0200 (CEST) From: Thomas Gleixner To: Nicolas Pitre cc: linux-kernel@vger.kernel.org Subject: Re: [PATCH/RFC] cpuhp code and data usage on UP systems In-Reply-To: Message-ID: References: User-Agent: Alpine 2.20 (DEB 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Linutronix-Spam-Score: -1.0 X-Linutronix-Spam-Level: - X-Linutronix-Spam-Status: No , -1.0 points, 5.0 required, ALL_TRUSTED=-1,SHORTCIRCUIT=-0.0001 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 2 Oct 2017, Nicolas Pitre wrote: > > On !SMP systems, we end up with the following array definition: > > static struct cpuhp_step cpuhp_ap_states[] = { > [CPUHP_ONLINE] = { > .name = "online", > .startup.single = NULL, > .teardown.single = NULL, > }, > }; > > where CPUHP_ONLINE = 187. That means up to 99.5% of this array is unused > but still allocated in the kernel's .data section i.e. 3760 bytes. > > The same issue exists with cpuhp_bp_states being 1720 bytes. > > The goal of this patch is mainly about illustrating the issue and > reducing .data usage. I have no clear idea when this stuff is really > needed besides standard CPU hotplug. Not knowing exactly what I'm doing > here, I made it conditional on CONFIG_SMP for now. There might be a case > for moving that code to a separate file (cpuhp.c maybe?) and omitting it > from the kernel when unneeded. > > Comments? Sure. > +#ifdef CONFIG_CPUHP > +#define ___P(proto, def_retcode) extern proto; > +#else > +#define ___P(proto, def_retcode) static inline proto { return def_retcode } > +#endif > + > +___P( > int __cpuhp_setup_state(enum cpuhp_state state, const char *name, bool invoke, > int (*startup)(unsigned int cpu), > - int (*teardown)(unsigned int cpu), bool multi_instance); > - > + int (*teardown)(unsigned int cpu), bool multi_instance), 0; ) What exactly is invoking the callbacks of states in the proper context and manages instances on registration? Ditto for teardwon in case of modules. Thanks, tglx