Rob Landley wrote: > On Friday 30 January 2009 09:01:34 Andy Whitcroft wrote: >> On Thu, Jan 29, 2009 at 12:50:32PM -0600, Rob Landley wrote: >> > The help option in mm/Kconfig says: >> > > help >> > > SPARSEMEM_VMEMMAP uses a virtually mapped memmap to optimise >> > > pfn_to_page and page_to_pfn operations. This is the most >> > > efficient option when sufficient kernel resources are available. >> > >> > This doesn't really tell me what it does, what the plusses and minuses >> > are, or when I would or wouldn't need to select it. I don't have enough >> > information to make this config selection (what are "sufficient kernel >> > resources"? Would a 256 meg qemu image qualify?), and the help isn't >> > helping. >> >> Hmmm. >> >> SPARSEMEM_VMEMMAP enables use of a memmap contigious in the kernel >> virtual address space, this allows optimised access to the memmap. It >> does consume more kernel virtual address space and is not suitable for >> processors with limited virtual address for the kernel (such as i386). > > Maps all physical memory into a single virtually contiguous address range, > which turns most of the remapping functions into NOPs. Check. > >> > Looking at the commit, the comment is: >> > > SPARSEMEM_VMEMMAP needs to be a selectable config option to support >> > > building the kernel both with and without sparsemem vmemmap support. >> > > This selection is desirable for platforms which could be configured one >> > > way for platform specific builds and the other for multi-platform >> > > builds. >> > >> > Once again, how does someone configuring a system make a decision? >> > Apparently you know, but this documentation isn't saying what the >> > decision criteria or requirements/benefits are. >> >> If you have lots of virtual address space such as on 64 bit processors >> you should be enabling it. For smaller processors it is appropriate >> where the memory is mostly contigious physically. > > Why would the memory mostly being physically contiguous matter? (This _makes_ > it physically contiguous, it's virtual address space being exhausted, right?) > > Also, why is this a user-visible option? On x86-64 it sounds like there's > never a reason to disable it, what with a 48 bit physical address range and a > 64 bit virtual one. On 32 bit, if you'd only want to enable it for systems > with small amounts of physical memory (so as not to consume your virtual > address range) then couldn't it be tied to CONFIG_NOHIGHMEM or something? It should be turned off for systems that have little RAM compared with how many VMEMMAP entries are used. The trade off is speed for size. The VMEMMAP entries take up memory. It needs to be selectable so distros can make an image that runs on all platforms they target, but which may not be optimal for all those platforms, and yet the optimal setting can be selected when building for a specific platform. -Geoff -- 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
