On Thu, Jun 4, 2009 at 7:22 PM, John McCabe-Dansted <[email protected]> wrote: > 2009/4/2 Nitin Gupta <[email protected]>: >> On Thu, Apr 2, 2009 at 7:39 AM, Christoph Lameter <[email protected]> wrote: >>> On Thu, 2 Apr 2009, Nitin Gupta wrote: >>> >>>> Justification for this custom allocator is present in xvmalloc changelog >>>> itself. It gives reason for not using SLUB and SLOB. During review >>>> cycle, I never got any arguments against that justification. >>> >>> The use of highmem is pretty unique. But that restrict the usefulness to >>> 32 bit processors with too much RAM. > > Does this mean that installing compcache on a 4GB machine would allow > the top 1GB of RAM to be used for something without the overhead of > enabling to PAE options (which I presume are HIGHMEM4G/HIGHMEM64G)? >
It is fundamentally not possible to use 4G memory without PAE - so neither can compcache. Without PAE, physical address space is just 32-bit. Out of this, some part is reserved for PCI devices, ACPI etc. - you can see this in BIOS "e820" map shown very early during boot-up. In some cases, it is even possible that BIOS maps only ~2G of PA space to RAM - so, if you have 4G RAM on such system, ~2G is unusable. xvmalloc support for highmem means that: - on 32-bit systems without PAE: we can use all the memory exposed in e820 map (which is typically 2G-3G on system with 4G RAM, depending on kind of devices you have). - on 32-bit system with PAE: physical address space is 2^36 (64G). So, we can use all memory available. So, in summary, xvmalloc is not restricted by small VA space on 32-bit systems. Only limitation is how much memory system can access. Thanks, Nitin _______________________________________________ linux-mm-cc mailing list [email protected] http://lists.laptop.org/listinfo/linux-mm-cc
