[linux-mm-cc] compcache-0.5pre1 release

[John McCabe-Dansted]

On Sat, Dec 27, 2008 at 3:20 AM, Nitin Gupta <nitingupta910 at gmail.com> wrote:
>
> This seems to be the _only_ way for now. Real thing would be to let

I was thinking that extending to support up to page size xvmalloc
might be cleaner. OTOH, on a 4K page machine 512 bytes is 12.5% which
isn't that much more than the fragmentation of xvmalloc, so we do not
gain much.

> such pages go to real swap disk (if present). But till the time that
> is implemented we should allocate full page to keep it or just return
> I/O error as we currently do. It seems that if we return too many swap
> I/O errors, we get into some problems (need to check block layer
> stuff?).
>
> In your code:
>  + compcache.table[page_no].pageNum=(u32)(cmem);
>
> you are casting virtual address to u32. This will surely segfault on
> 64bit. Maybe this is the reason for crash.

No. I am running this in a 32bit VM. The patch does not presently
attempt to support 64bit machines. The crash was caused by the lines
in the initialisation:

        compcache.table[0].pageNum = page_to_pfn(page);
        compcache.table[0].len = PAGE_SIZE;

I have worked around this by checking if page_no == 0, however it
would probably be  better to replace the above first line with
something like:

           compcache.table[0].pageNum = pointer_to_page(page);

I can think of three ways of supporting 64bit:
1) Expand the compcache table (wasteful of space)
2) Steal bits from 64bit pointers (rather unclean)
3) Allocate 64bits with xvmalloc
4) Allocate 64bits from xvmalloc  iff pointer > MAX_U32.

4) seems the nicest of these options.

> Nit: you are using GFP_KERNEL alloc flag with kmalloc - this can cause
> deadlock: alloc memory to store compressed page -> not enough memory,
> swap out something -> alloc memory to store compressed page -> ...and
> this goes on.
> So GFP_NOIO should be used.

OK.

FYI, I have attached another patch. This fixes the above error, but
there is still another bug. AFAICT now all page reads report that
decompression failed. I do not know what causes this bug, and this
patch is still  filled with extra pr_info("Debug ...") lines to help
my try to track this down. I'll look into this as time permits.

-- 
John C. McCabe-Dansted
PhD Student
University of Western Australia
-------------- next part --------------
A non-text attachment was scrubbed...
Name: compcache.c.diff
Type: text/x-diff
Size: 8251 bytes
Desc: not available
Url : http://lists.laptop.org/pipermail/linux-mm-cc/attachments/20081228/d0d4b07a/attachment.diff