[PATCH 2/3] arm: Add config option for HOLES_IN_ZONE

[mbohan@codeaurora.org (Michael Bohan)]

On 4/2/2010 2:56 AM, Mel Gorman wrote:
> Have you managed to trigger this problem? I am assuming you are not
> referring to page migration as such but more likely when pages shuffle
> between lists in move_freepages(). To trigger a problem there, I think
> you would have to have a memory layout that had an
> max-order-unaligned-hole in the middle of a zone. Is that happening?
>    

Yes, that is exactly what's happening.  I communed with you some time 
ago regarding this problem.  I see crashes in move_freepages_block() 
without this patch.

> If so, another possibility you may want to consider (if you haven't
> already) is to ensure in free_memmap() that if holes are being punched
> in the middle of a zone that they are only max-order aligned. This would
> avoid corruption problems without taking a performance hit.
>    

I did consider this.  The only problem here is that for each unaligned 
memory hole, we waste some more amount of memory (8, 16, or 24KB) 
assuming 1 MB aligned end addresses and MAX_ORDER == 11.  That doesn't 
sound that bad, but there's always the chance that somebody has a lot of 
holes in their memory map.    I suppose it's not truly 'wasted' in the 
sense that it's necessary for correctness; and I agree that it may be 
better than taking a run-time performance hit.

As you suggested, it's not easy to quantify what sort of performance hit 
we're taking.  Without solid data, it might be safer to go your 
suggested route of freeing only legitimate memmap entries.  I will test 
on my end that this does indeed keep the allocator happy (eg. no 
crashes) and does not cause any bad observable side effects.

I guess the only questions for linux-arm-kernel is whether they would be 
okay with freeing a little less memmap in the case of unaligned bank end 
addresses, and whether they think this warrants an info message to the 
user during bootup that they should consider aligning them to save a 
little memory.

Thanks,
Michael