Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755565AbZDPXYz (ORCPT ); Thu, 16 Apr 2009 19:24:55 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1754283AbZDPXYq (ORCPT ); Thu, 16 Apr 2009 19:24:46 -0400 Received: from smtp1.linux-foundation.org ([140.211.169.13]:54918 "EHLO smtp1.linux-foundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751751AbZDPXYp (ORCPT ); Thu, 16 Apr 2009 19:24:45 -0400 Date: Thu, 16 Apr 2009 16:18:34 -0700 (PDT) From: Linus Torvalds X-X-Sender: torvalds@localhost.localdomain To: Yinghai Lu cc: Ingo Molnar , Jesse Barnes , "H. Peter Anvin" , Andrew Morton , Thomas Gleixner , "linux-kernel@vger.kernel.org" , linux-pci@vger.kernel.org, yannick.roehlly@free.fr Subject: Re: [PATCH] x86/pci: make pci_mem_start to be aligned only -v4 In-Reply-To: <49E7916C.7050701@kernel.org> Message-ID: References: <49E00E9F.8030605@kernel.org> <49E4F6D6.6030709@kernel.org> <49E4F71F.10107@kernel.org> <49E52A7A.4070607@kernel.org> <49E52D3F.1090206@kernel.org> <20090416093152.6605612d@hobbes> <20090416165640.GA13927@elte.hu> <49E76864.9060309@kernel.org> <20090416172803.GB16618@elte.hu> <49E7916C.7050701@kernel.org> User-Agent: Alpine 2.00 (LFD 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2787 Lines: 92 On Thu, 16 Apr 2009, Yinghai Lu wrote: > > please check. > > [PATCH] x86/pci: make pci_mem_start to be aligned only -v4 I like the approach. That said, I think that rather than do the "modify the e820 array" thing, why not just do it in the in the resource tree, and do it at "e820_reserve_resources_late()" time? IOW, something like this. TOTALLY UNTESTED! The point is to take all RAM resources we haev, and _after_ we've added all the resources we've seen in the E820 tree, we then _also_ try to add fake reserved entries for any "round up to X" at the end of the RAM resources. NOTE! I really didn't want to use "reserve_region_with_split()". I didn't want to recurse into any conflicting resources, I really wanted to just do the other failure cases. THIS PATCH IS NOT MEANT TO BE USED. Just a rough "almost like this" kind of thing. That includes the rough draft of how much to round things up to based on where the end of RAM region is etc. I'm really throwing this out more as a "wouldn't this be a readable way to handle any missing reserved entries" kind of thing.. Linus --- arch/x86/kernel/e820.c | 34 ++++++++++++++++++++++++++++++++++ 1 files changed, 34 insertions(+), 0 deletions(-) diff --git a/arch/x86/kernel/e820.c b/arch/x86/kernel/e820.c index ef2c356..e8b8d33 100644 --- a/arch/x86/kernel/e820.c +++ b/arch/x86/kernel/e820.c @@ -1370,6 +1370,23 @@ void __init e820_reserve_resources(void) } } +/* How much should we pad RAM ending depending on where it is? */ +static unsigned long ram_alignment(resource_size_t pos) +{ + unsigned long mb = pos >> 20; + + /* To 64kB in the first megabyte */ + if (!mb) + return 64*1024; + + /* To 1MB in the first 16MB */ + if (mb < 16) + return 1024*1024; + + /* To 32MB for anything above that */ + return 32*1024*1024; +} + void __init e820_reserve_resources_late(void) { int i; @@ -1381,6 +1398,23 @@ void __init e820_reserve_resources_late(void) insert_resource_expand_to_fit(&iomem_resource, res); res++; } + + /* + * Try to bump up RAM regions to reasonable boundaries to + * avoid stolen RAM + */ + for (i = 0; i < e820.nr_map; i++) { + struct e820entry *entry = &e820_saved.map[i]; + resource_size_t start, end; + + if (entry->type != E820_RAM) + continue; + start = entry->addr + entry->size; + end = round_up(start, ram_alignment(start)); + if (start == end) + continue; + reserve_region_with_split(&iomem_resource, start, end, "RAM buffer"); + } } char *__init default_machine_specific_memory_setup(void) -- 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/