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? > Does that help at all? Well, I feel I've attained a higher level of ignorance, so yes. Thanks. :) > -apw Rob -- 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
