From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933320AbbESP5W (ORCPT ); Tue, 19 May 2015 11:57:22 -0400 Received: from 251.110.2.81.in-addr.arpa ([81.2.110.251]:32906 "EHLO lxorguk.ukuu.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755306AbbESP5U (ORCPT ); Tue, 19 May 2015 11:57:20 -0400 Date: Tue, 19 May 2015 16:56:30 +0100 From: One Thousand Gnomes To: David Woodhouse Cc: Joe Perches , Rusty Russell , LKML , Quentin Casasnovas Subject: Re: mod_devicetable: Make dmi_strmatch.substr const char * Message-ID: <20150519165630.169c64d3@lxorguk.ukuu.org.uk> In-Reply-To: <1432018018.3277.22.camel@infradead.org> References: <1431994055.2870.102.camel@perches.com> <1432018018.3277.22.camel@infradead.org> Organization: Intel Corporation X-Mailer: Claws Mail 3.11.1 (GTK+ 2.24.27; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 19 May 2015 07:46:58 +0100 David Woodhouse wrote: > On Mon, 2015-05-18 at 17:07 -0700, Joe Perches wrote: > > > > changed dmi_strmatch.substr from char * to char[79]; > > > > Changing it back to const char * would shrink an x86-64 > > defconfig more than 100KB. > > > > $ size vmlinux.old vmlinux.new > > text data bss dec hex filename > > 11941725 1825624 1085440 14852789 e2a2b5 vmlinux.old > > 11921172 1730648 1085440 14737260 e0df6c vmlinux.new What percentage of those are __initdata ? > > modpost has changed a bit since 2008, is it's time to change it back? > > Does the match table stuff still work if you do that? I thought the > point in changing to an array was to make the table extraction do the > right thing because it can't follow pointers... Can't follow, or can't currently follow. All the data needed appears to exist. If you are trying to build a compact kernel with no modules then you can certainly make them pointers. A more serious and invasive fix would be to make substr a u32 and replace the text in the match with a Rabin-Karp or other rolling hash value, then do a rolling hash for the match. As we've got zlib in the kernel I assume we have the hash to hand ? The same could be applied to a lot of the other matchers although with drastically reduced results as they don't have 320 bytes of match bloating each single entry. It does however mean something would have to do the substitutions at compile time, either by writing the rolling hash as a recursive preprocessor macro or having a tool in the path which is ugly. Alan