FYI: compcache is in mainline (scheduled for 2.6.33)

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

FYI: compcache is in mainline (scheduled for 2.6.33)

Nelson Castillo-2
This code is in mainline now.:

http://code.google.com/p/compcache/

It might be useful for the FR.

Reply | Threaded
Open this post in threaded view
|

Re: FYI: compcache is in mainline (scheduled for 2.6.33)

Patryk Benderz
Dnia 2010-01-06, śro o godzinie 04:06 -0500, Nelson Castillo pisze:
> This code is in mainline now.:
>
> http://code.google.com/p/compcache/
>
> It might be useful for the FR.
Hi Nelson,
Thanks for showing this up. From project's page: "Compressing pages and
keeping them in RAM virtually increases its capacity." Keep in mind that
with current FreeRunner's performance problems, adding additional
overhead to compress pages might actually result in decreasing FR's
performance. But this is just my opinion. Best would be to test, how it
behaves with FR, or listen to someone's opinion, who knows how it works
under the hood ;)

--
Patryk "LeadMan" Benderz
Linux Registered User #377521
()  ascii ribbon campaign - against html e-mail
/\  www.asciiribbon.org   - against proprietary attachments


Email secured by Check Point

Reply | Threaded
Open this post in threaded view
|

Re: FYI: compcache is in mainline (scheduled for 2.6.33)

Nicolas Dufresne
Le mercredi 06 janvier 2010 à 16:24 +0100, Patryk Benderz a écrit :
overhead to compress pages might actually result in decreasing FR's
Note that this is all about in RAM swap. If we saturate the RAM on FR and use flash for SWAP, you end up with something just unusable. Considering this feature, you reduce RAM space which will cause swapping, but the swap access is a lot faster. With this feature we could augment caching within software and kernel and reduce IOs to the SD cards (which are very slow on this phone).
Reply | Threaded
Open this post in threaded view
|

Re: FYI: compcache is in mainline (scheduled for 2.6.33)

Nelson Castillo-2
On Wed, Jan 6, 2010 at 11:47 AM, Nicolas Dufresne
<[hidden email]> wrote:
> Le mercredi 06 janvier 2010 à 16:24 +0100, Patryk Benderz a écrit :
>
> overhead to compress pages might actually result in decreasing FR's

The LZO compression algorithm is very fast. I've used LZO it a few times.
http://en.wikipedia.org/wiki/LZO

> Note that this is all about in RAM swap. If we saturate the RAM on FR and
> use flash for SWAP, you end up with something just unusable. Considering
> this feature, you reduce RAM space which will cause swapping, but the swap
> access is a lot faster. With this feature we could augment caching within
> software and kernel and reduce IOs to the SD cards (which are very slow on
> this phone).

I had a good experience with compcache about one and half years ago on
a IA-32 laptop with 256MB of RAM. By then it was unstable on the ARM
so I didn't try it.

I would try a small swap (10M?) in RAM with higher priority and the
usual SD card swap space.

But later... right now upstream is crashing and I still haven't
found/looked for the cause :-/