[linux-mm-cc] [PATCH 0/3] compressed in-memory swapping take5

[Nitin Gupta]

On Thu, Jun 4, 2009 at 7:22 PM, John McCabe-Dansted <gmatht at gmail.com> wrote:
> 2009/4/2 Nitin Gupta <ngupta at vflare.org>:
>> On Thu, Apr 2, 2009 at 7:39 AM, Christoph Lameter <cl at linux.com> 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