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

[John McCabe-Dansted]

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)?

http://lkml.org/lkml/2000/8/3/50 -- Overhead of PAE
http://kerneltrap.org/node/2450 -- Discussion of highmem

I have been reading documentation on highmem, but I am still not sure
if compcache can use this RAM without the entire OS having to suffer
the PAE penalty.

If so, it would sound like a good idea to load compcache by default on
4GB 32bit Ubuntu machines. Obviously I'd want benchmarks to justify
this, but first I'd like to know if it was theoretically possible.

-- 
John C. McCabe-Dansted
PhD Student
University of Western Australia