Re: [patch 0/4] ia64 SPARSEMEM

[Bob Picco <bob.picco@hp.com>]

luck wrote:	[Wed May 25 2005, 08:32:54PM EDT]
> 
> >+#ifdef CONFIG_SPARSEMEM
> >+ /*
> >+ * SECTION_SIZE_BITS            2^N: how big each section will be
> >+ * MAX_PHYSADDR_BITS            2^N: how much physical address space we have
> >+ * MAX_PHYSMEM_BITS             2^N: how much memory we can have in that space
> >+ */
> 
> MAX_PHYSADDR_BITS is apparently never used ... what's the distinction
Ah MAX_PHYSADDR_BITS appears not used by all arches ported to SPARSEMEM.  I 
wonder if it's a remnant of NONLINEAR.  Dave, do you recall?
> between it and MAX_PHYSMEM_BITS?  From the comments, I'd guess that you
> really meant to use MAX_PHYSADDR_BITS in this:
> 
> #define SECTIONS_SHIFT          (MAX_PHYSMEM_BITS - SECTION_SIZE_BITS)
> 
> Pursuing Jack Steiner's line of questioning on how this works for
> the SGI Altix ... it would appear that he will need to use 50 for
> MAX_PHYSMEM_BITS, and probably 32 for SECTION_SIZE_BITS (but maybe
I went back and reviewed Jack's email.  I must be blind but don't see why
he would need more than 44 bits of physical memory bits.  I agree that
should you need 50 bits for physical address bits then you should use
32 bits for SECTION_SIZE_BITS.
> a smaller number ... his banks of memory all start on 4G boundaries,
> but could be as small as 1G ... can you have a chunk with an empty
> tail?).  So SGI will end up with 2^(50-32) = 256K entries in mem_section[]
> (or perhaps 4x that if sections must be fully populated).  All allocated
> on the boot node ... and perhaps consuming a significant portion of
> the kernel memory mapped by dtr[0].
Well worse case it would consume 2^(1(50-32)+3) (2 Mb).  I would hope that 
it's not configured for 28 SECTION_SIZE_BITS and 50 physical. This would
be excessive 2^((50-28)+3 = 32Mb and not advised.
> 
> 
> It will be interesting to see performance numbers on how this compares
> with against VIRTUAL_MEM_MAP ... trading cache misses vs. TLB misses.
> 
> -Tony
bob