Re: [Bug 25042] New: RAM buffer I/O resource badly interacts with memory hot-add

[Linus Torvalds <torvalds@linux-foundation.org>]

On Tue, Jan 4, 2011 at 1:51 PM, Andrew Morton <akpm@linux-foundation.org> wrote:
>> Linus's commit 45fbe3ee01b8e463b28c2751b5dcc0cbdc142d90 in May 2009 added code
>> to create 'RAM buffer' above top of RAM to ensure that I/O resources do not
>> start immediately after RAM, but sometime later.  Originally it was enforcing
>> 32MB alignment, now it enforces 64MB.  Which means that in VMs with memory size
>> which is not multiple of 64MB there will be additional 'RAM buffer' resource
>> present:
>>
>> 100000000-1003fffff : System RAM
>> 100400000-103ffffff : RAM buffer

I'd suggest just working around it by hotplugging in 64MB chunks.

IOW, the old "it hurts when I do that - don't do that then" solution
to the problem. There is no reason why a VM should export some random
8MB-aligned region that I can see.

>> Another approach is resurrecting
>> http://linux.derkeiler.com/Mailing-Lists/Kernel/2008-07/msg06501.html and using
>> this range instead of all "unclaimed" ranges for placing I/O devices.  Then
>> "RAM buffer" would not be necessary at all.

Yeah, not going to happen. There's no point (see above), and it is
fundamentally wrong to even think that the firmware tables - ACPI or
otherwise - would be so perfect that you can just always trust them.
Every time somebody makes the mistake of thinking they can do that
(and it happens distressingly often), they are quickly shown to be
wrong, and there's some random hardware out there that simply doesn't
list the ranges it uses.

What could happen these days is to move the "gap" logic from the e820
table (and /proc/iomem) and into the "arch_remove_reservations()"
logic. See commit fcb119183c73bf0781009713f303e28b1fb13d3e. That might
make memory hotplug happier.

That said, I do repeat: why the hell do you keep digging that hole in
the first place. Do memory hotplug in 256MB chunks, naturally aligned,
and don't bother with any of this crazy crap.

                     Linus

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom policy in Canada: sign http://dissolvethecrtc.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>