Re : sparsemem usage

[moreau francis]

Andy Whitcroft wrote:
> The memory allocator buddy location algorithm has an implicit assumption 
> that the memory map will be contigious and valid out to MAX_ORDER.  ie 
> that we can do relative arithmetic on a page* for a page to find its 
> buddy at all times.  The allocator never looks outside a MAX_ORDER 
> block, aligned to MAX_ORDER in physical pages.  SPARSEMEM's 
> implementation by it nature breaks up the mem_map at the section size. 
> Thus for the buddy to work a section must be >= MAX_ORDER in size to 
> maintain the contiguity constraint.

thanks for the explanation. But still something I'm missing, how can a
MAX_ORDER block be allocated in a memory whose size is only 128Ko ?
Can't it be detected by the buddy allocatorvery early without doing any 
relative arithmetic on a page* ?

> However, just because you have a small memory block in your memory map 
> doesn't mean that the sparsemem section size needs to be that small to 
> match.  If there is any valid memory in any section that section will be 
> instantiated and the valid memory marked within it, any invalid memory 
> is marked reserved.  

ah ok but that means that pfn_valid() will still returns ok for invalid page which
are in a invalid memory marked as reserved. Is it not risky ?

> The section size bounds the amount of internal 
> fragmentation we can have in the mem_map.  SPARSEMEM as its name 
> suggests wins biggest when memory is very sparsly populate. 

sorry but I don't understand. I would say that sparsemem section size should
be chosen to make mem_map[] and mem_section[] sizes as small as possible.

> If I am 
> reading correctly your memory is actually contigious.

well there're big holes in address space.

thanks

Francis




-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/