[prev in list] [next in list] [prev in thread] [next in thread] 

List:       olpc-linux-mm-cc
Subject:    Re: [linux-mm-cc] compcache-0.5pre4 released
From:       "John McCabe-Dansted" <gmatht () gmail ! com>
Date:       2009-01-13 5:59:45
Message-ID: fd87b6160901122159x7322c632p267276120a2c548a () mail ! gmail ! com
[Download RAW message or body]

On Mon, Jan 12, 2009 at 3:10 AM, Nitin Gupta <nitingupta910@gmail.com> wrote:
> On Sun, Jan 11, 2009 at 7:47 PM, John McCabe-Dansted <gmatht@gmail.com> wrote:
>> Seems solid on 32bit hardy. However, I am getting 26% more memory
>> allocated than used (with regression.sh, attached):
>>
>> OrigDataSize:     221980 kB
>> ComprDataSize:    129086 kB
>> MemUsed:          163116 kB
>>
>> XvMalloc got within 12% of ideal in all your tests. I take it ideal is
>> not the same as zero fragmentation?
>>
>
> "Ideal" allocator is same as zero fragmentation. However your
> particular case seems to have trigerred some bad case behavior. One
> such bad case is, if threre are too many compressed pages with size
> just > PAGE_SIZE/2 - in this case we will end up allocating 1 full 4k
> page for every compressed page. To analyze further, it will be great

Yes, GoodCompress is at 20%. Which is odd because I am just filling
memory with sequential integers, so the memory is very easy to
compress, but perhaps not with LZO. WKdm sounds like it would handle
this case very well.

Perhaps sometime I will compare compressed sizes of LZO vs WKdm vs
best of both to test the idea that having two layers of compcache is
worthwhile.

-- 
John C. McCabe-Dansted
PhD Student
University of Western Australia
_______________________________________________
linux-mm-cc mailing list
linux-mm-cc@lists.laptop.org
http://lists.laptop.org/listinfo/linux-mm-cc
[prev in list] [next in list] [prev in thread] [next in thread]