[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4DA61F8D.3000005@zytor.com>
Date: Wed, 13 Apr 2011 15:11:25 -0700
From: "H. Peter Anvin" <hpa@...or.com>
To: Yinghai Lu <yinghai@...nel.org>
CC: Joerg Roedel <joro@...tes.org>, Ingo Molnar <mingo@...e.hu>,
Alex Deucher <alexdeucher@...il.com>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
dri-devel@...ts.freedesktop.org,
Thomas Gleixner <tglx@...utronix.de>, Tejun Heo <tj@...nel.org>
Subject: Re: Linux 2.6.39-rc3
On 04/13/2011 02:59 PM, Yinghai Lu wrote:
> On 04/13/2011 02:50 PM, Joerg Roedel wrote:
>> On Wed, Apr 13, 2011 at 01:48:48PM -0700, Yinghai Lu wrote:
>>> - addr = memblock_find_in_range(0, 1ULL<<32, aper_size, 512ULL<<20);
>>> + addr = memblock_find_in_range(0, 1ULL<<32, aper_size, 512ULL<<21);
>>
>> Btw, while looking at this code I wondered why the 512M goal is enforced
>> by the alignment. Start could be set to 512M instead and the alignment
>> can be aper_size as it should. Any reason for such a big alignment?
>>
>
> when using bootmem, try to use big alignment (512M ), so we could avoid take ram range below 512M.
>
Yes, his question was why on Earth are you using 0 as start if that is
the purpose.
On top of that, where the hell does the magic 512 MiB come from? It
looks like it is either completly ad hoc, or it has something to do with
where the kexec kernel was allocated once upon a time.
-hpa
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists