On Tue, Jul 13, 2010 at 09:32:50PM +0100, Mel Gorman wrote: > On Tue, Jul 13, 2010 at 06:37:44PM +0100, Russell King - ARM Linux wrote: > > You're saying that MAX_PHYSMEM_BITS=29 SECTION_SIZE_BITS=26 is wrong. > > > > Not wrong. It's fine as long as you're ok with some unnecessary memmap > being allocated. There is wastage of memory but functionally it'll be > fine with existing sparsemem and the assumptions it makes. > > Obviously you're not ok with this wastage or this discussion would not even > be happening and with SECTION_SIZE_BITS=26, there is quite a bit of wastage. Absolutely I'm not ok with this wastage - it's 127 + 127 + 64 pages, or 1.2MB - that's 4% of system memory wasted in stuff which isn't going to be used. Moreover, the mem_map array for each populated bank is 512K - which is the size of the RAM in the first two banks. At that point, there's absolutely no point in populating them. The overhead of populating those banks exactly equals the gain from populating them. Sparsemem is absolutely absurd in this requirement - it can't handle sparse memory efficiently without wasting lots of memory in the process. > I haven't researched this so apologies if it turns out to be stupid but > I think the bit SECTION_MAP_LAST_BIT is actually unused and should be > safe to use. Has the option being considered of using this bit to mean > "section has holes punched in it". If set, the architecture must provide > an additional arch_holey_section_pfn_valid() that does additional checking > based on information sparsemem doesn't have? This would avoid the worst of > the performance issues of making pfn_valid() slower without increasing the > size of mem_section. As I've already said, how about just allowing pfn_valid() to be overridden by architectures, even for the sparsemem case. We have a perfectly good pfn_valid() implementation that'll work across the board, and will fix this issue. -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
 |