From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757951AbcIRSMD (ORCPT ); Sun, 18 Sep 2016 14:12:03 -0400 Received: from mx1.redhat.com ([209.132.183.28]:40750 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753274AbcIRSL4 (ORCPT ); Sun, 18 Sep 2016 14:11:56 -0400 Subject: Re: [PATCH 2/2 v2] x86/e820: Use much less memory for e820/e820_saved, save up to 120k To: Ingo Molnar References: <20160909075827.14602-1-dvlasenk@redhat.com> <20160915070430.GA25643@gmail.com> <494d4f1a-272f-4ee4-d184-6d6645584012@redhat.com> <20160918083127.GA15186@gmail.com> Cc: Andy Lutomirski , "H. Peter Anvin" , Borislav Petkov , Brian Gerst , x86@kernel.org, linux-kernel@vger.kernel.org From: Denys Vlasenko Message-ID: Date: Sun, 18 Sep 2016 20:11:53 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <20160918083127.GA15186@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.31]); Sun, 18 Sep 2016 18:11:55 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 09/18/2016 10:31 AM, Ingo Molnar wrote: > * Denys Vlasenko wrote: >> On 09/15/2016 09:04 AM, Ingo Molnar wrote: >>> * Denys Vlasenko wrote: >>> >>>> The maximum size of e820 map array for EFI systems is defined as >>>> E820_X_MAX (E820MAX + 3 * MAX_NUMNODES). >>>> >>>> In x86_64 defconfig, this ends up with E820_X_MAX = 320, e820 and e820_saved >>>> are 6404 bytes each. >>>> >>>> With larger configs, for example Fedora kernels, E820_X_MAX = 3200, e820 and e820_saved >>>> are 64004 bytes each. Most of this space is wasted. Typical machines have some 20-30 >>>> e820 areas at most. >>>> >>>> This patch turns e820 and e820_saved to pointers which initially point to __initdata >>>> tables, of the same size as before. >>>> >>>> At the very end of setup_arch(), when we are done fiddling with these maps, >>>> allocate smaller alloc_bootmem blocks, copy maps there, and change pointers. >>>> >>>> Run-tested. >>> >>>> +/* >>>> + * Initial e820 and e820_saved are largish __initdata arrays. >>>> + * Copy them to (usually much smaller) dynamically allocated area. >>>> + * This is done after all tweaks we ever do to them. >>>> + */ >>>> +__init void e820_reallocate_tables(void) >>>> +{ >>>> + struct e820map *n; >>>> + int size; >>>> + >>>> + size = offsetof(struct e820map, map) + sizeof(struct e820entry) * e820->nr_map; >>>> + n = alloc_bootmem(size); >>>> + memcpy(n, e820, size); >>>> + e820 = n; >>>> + >>>> + size = offsetof(struct e820map, map) + sizeof(struct e820entry) * e820_saved->nr_map; >>>> + n = alloc_bootmem(size); >>>> + memcpy(n, e820_saved, size); >>>> + e820_saved = n; >>>> +} >>> >>> Ok, this makes me quite nervous, could you please split this into two patches so >>> that any fails can be nicely bisected to? >> >> No problem. >> >>> First patch only does the pointerization changes with a trivial placeholder >>> structure (full size, static allocated), second patch does all the dangerous bits >>> such as changing it to __initdata, allocating and copying over bits. >>> >>> Also, could we please also add some minimal debugging facility to make sure the >>> memory table does not get extended after it's been reallocated? >> >> I have another idea: run e820_reallocate_tables() later, just before >> we free __init and __initdata. Then e820 tables _can't_ be_ changed - >> all functions which do that are __init functions. >> >> Will test this now, and send a patchset. > > Could we also mark it __ro_after_init? __ro_after_init makes sense only for statically allocated objects. e820_reallocate_tables() copies e280 maps to kmalloced memory.