On 09/04/2013 08:37 AM, Toshi Kani wrote:
On Tue, 2013-08-27 at 17:37 +0800, Tang Chen wrote:
memblock_alloc_base_nid() is a common API of memblock. And it calls
memblock_find_in_range_node() with %start = 0, which means it has no
limit for the lowest address by default.
memblock_find_in_range_node(0, max_addr, size, align, nid);
Since we introduced current_limit_low to memblock, if we have no limit
for the lowest address or we are not sure, we should pass
MEMBLOCK_ALLOC_ACCESSIBLE to %start so that it will be limited by the
default low limit.
dma_contiguous_reserve() and setup_log_buf() will eventually call
memblock_alloc_base_nid() to allocate memory. So if the allocation order
is from low to high, they will allocate memory from the lowest limit
to higher memory.
This requires the callers to use MEMBLOCK_ALLOC_ACCESSIBLE instead of 0.
Is there a good way to make sure that all callers will follow this rule
going forward? Perhaps, memblock_find_in_range_node() should emit some
message if 0 is passed when current_order is low to high and the boot
option is specified?
How about set this as the default rule:
When using from low to high order, always allocate memory from
current_limit_low.
So far, I think only movablenode boot option will use this order.
Similarly, I wonder if we should have a check to the allocation size to
make sure that all allocations will stay small in this case.
We can check the size. But what is the stragety after we found that the
size
is too large ? Do we refuse to allocate memory ? I don't think so.
I think only relocate_initrd() and reserve_crachkernel() could allocate
large
memory. reserve_crachkernel() is easy to reorder, but reordering
relocate_initrd()
is difficult because acpi_initrd_override() need to access to it with va.
I think on most servers, we don't need to do relocate_initrd(). initrd
will be
loaded to mapped memory in normal situation. Can we just leave it there ?
Thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
