linuxcompressed-devel — Linux Compressed Cache Development Mailing List

Re: [lc-devel] Memory leak detection tests on compressed cache code

[Nitin G. <nit...@gm...>]

Hi,

On 11/9/06, Allan Bezerra <all...@gm...> wrote:
>
>  Test showed that ***no memory leaks*** was found in compressed cache code.
> :-)
>

Wow! :-)

The biggest thing that remains is making all this stable when ccache
size is set to realistic values and then all the fancy adaptive
resizing stuff :-)


Cheers,
Nitin

[lc-devel] Memory leak detection tests on compressed cache code

[Allan B. <all...@gm...>]

Hi All,

For those who may be interested, I made some tests to verify the presence
(or not) of memory leak in the cache compression code. For this, I used
latest kmemleak patch sent for LKML by Catalin Marinas:
http://homepage.ntlworld.com/cmarinas/kmemleak/patch-2.6.19-rc1-kmemleak-0.11.bz2

I tested this as: (like gupta tests)
RAM: 128MB
ccache for anon pages - size: 5MB (1280 pages)
ccache for page cache pages - size: 10MB (2560 pages)

Launched openoffice-writer, gimp, firefox, kate, konsole. Closed
these, re-opened, open some web-pages, some file in writer,
close all, open all again.

Test showed that ***no memory leaks*** was found in compressed cache code.
:-)

--------------------------------------------------------------
Usage:

* Set compressed cache size (in unit of no. of
pages) for anonymous(swap-cache) and
filesystem-backed(page-cache) pages respectively.
/proc/sys/vm/{max_anon_cc_size,max_fs_backed_cc_size}

* To display the possible memory leaks:

mount -t debugfs nodev /sys/kernel/debug
cat /sys/kernel/debug/memleak
-------------------------------------------------------------

Re: [lc-devel] Update Compressed cache alpha-007 to kernel 2.6.19

[Nitin G. <nit...@gm...>]

Hi Allan,

Great to know you are working on this!
Although I couldn't test your code but I just wanted to point out that
main thing that needs to be done now is to implement suggestions made
by Peterz -- see:
http://mailman.laptop.org/pipermail/linux-mm-cc/2006-September/000066.html

Regards,
Nitin

On 11/8/06, Allan Bezerra <all...@gm...> wrote:
> ------------
> Project: Compressed Caching for Linux
> Project Home: http://linuxcompressed.sourceforge.net
> Git (web):
> http://dev.laptop.org/git.do?p=projects/linux-mm-cc
> Git (git): git://dev.laptop.org/projects/linux-mm-cc
> ------------
>
> Hi Nitin and all!
>
> For those who may be interested, I update compressed cache patch to kernel
> 2.6.19.
> This patch has no significantly changes.
>
> * Changelog: ccache-alpha-007 (applies to 2.6.19)
>
> Cheers,
>
> -- Allan Bezerra
>
>

Re: [lc-devel] Announce: Compressed cache alpha-007 (kernel 2.6.18)

[Nitin G. <nit...@gm...>]

Nick Piggin wrote:
> On Wed, Sep 20, 2006 at 04:39:45PM +0200, Peter Zijlstra wrote:
>> On Wed, 2006-09-20 at 19:34 +0530, Nitin Gupta wrote:
>>> Peter Zijlstra wrote:
>>>> On Wed, 2006-09-20 at 18:23 +0530, Nitin Gupta wrote:
>>>>
>>>>>> Don't like the bit_spin_trylock/bit_spin_unlock in handle_ccache_fault;
>>>>>> what's wrong with TestSetPageLocked() and unlock_page() ?
>>>>>>
>>>>> If (PageCompressed(page)) is true then 'page' is 'struct chunk_head'
>>>>> not 'struct page' and you cannot use unlock_page() on chunk_head.
>>>> ClearPageLocked()
>>>>
>>> But then how will you do equivalent of wait_on_chunk_head() ?
>> Doh, now I see, its not &page->flags but &ch->flags.
>>
>> Humm, you'd need to open code this I think, bit_spin_trylock() may not
>> be ordered strong enough (on !x86). Got my head in a twist, but I think
>> this is correct:
>>
>> static inline
>> int chunk_head_trylock(struct chunk_head *ch)
>> {
>> 	int locked = test_set_bit(PG_locked, &ch->flags);
>> 	if (!locked)
>> 		smb_wmb();
>> 	return !locked;
>> }
>>
>> static inline
>> void chunk_head_unlock(struct chunk_head *ch)
>> {
>> 	int locked;
>> 	smp_wmb();
>> 	locked = test_clear_bit(PG_locked, &ch->flags);
>> 	BUG_ON(!locked);
>> }
> 
> A plain clear_bit(PG_locked, ...) here will leak, but all atomic and
> bitop RMW ops are defined to be strongly ordered before and after (by
> Documentation/atomic_ops.txt), so I think we're OK?
> 
> In your above examples, I think you probably want full smp_mb() there
> because you do want to prevent loads inside the critical section from
> being completed before the bit is visible or after the bit is cleared.
> 
> Nick
> 


I don't know much about SMP but since bit_spin_trylock() and gang is 
defined in arch independent path (include/linux/bit_spinlock.h) then 
shouldn't they be expected to provide proper locking on all archs? If 
there's known problem with them then shouldn't they be replaced with 
correct ones?

-- Nitin

Re: [lc-devel] Announce: Compressed cache alpha-007 (kernel 2.6.18)

[Peter Z. <a.p...@ch...>]

On Wed, 2006-09-20 at 17:12 +0200, Nick Piggin wrote:
> On Wed, Sep 20, 2006 at 04:39:45PM +0200, Peter Zijlstra wrote:
> > On Wed, 2006-09-20 at 19:34 +0530, Nitin Gupta wrote:
> > > Peter Zijlstra wrote:
> > > > On Wed, 2006-09-20 at 18:23 +0530, Nitin Gupta wrote:
> > > > 
> > > >>> Don't like the bit_spin_trylock/bit_spin_unlock in handle_ccache_fault;
> > > >>> what's wrong with TestSetPageLocked() and unlock_page() ?
> > > >>>
> > > >> If (PageCompressed(page)) is true then 'page' is 'struct chunk_head'
> > > >> not 'struct page' and you cannot use unlock_page() on chunk_head.
> > > > 
> > > > ClearPageLocked()
> > > > 
> > > 
> > > But then how will you do equivalent of wait_on_chunk_head() ?
> > 
> > Doh, now I see, its not &page->flags but &ch->flags.
> > 
> > Humm, you'd need to open code this I think, bit_spin_trylock() may not
> > be ordered strong enough (on !x86). Got my head in a twist, but I think
> > this is correct:
> > 
> > static inline
> > int chunk_head_trylock(struct chunk_head *ch)
> > {
> > 	int locked = test_set_bit(PG_locked, &ch->flags);
> > 	if (!locked)
> > 		smb_wmb();
> > 	return !locked;
> > }
> > 
> > static inline
> > void chunk_head_unlock(struct chunk_head *ch)
> > {
> > 	int locked;
> > 	smp_wmb();
> > 	locked = test_clear_bit(PG_locked, &ch->flags);
> > 	BUG_ON(!locked);
> > }
> 
> A plain clear_bit(PG_locked, ...) here will leak, but all atomic and
> bitop RMW ops are defined to be strongly ordered before and after (by
> Documentation/atomic_ops.txt), so I think we're OK?

Ah, yes, I read it like so:

They must execute atomically, yet there are no implicit memory barrier
semantics required of these interfaces.

        int test_and_set_bit(unsigned long nr, volatile unsigned long *addr);
        int test_and_clear_bit(unsigned long nr, volatile unsigned long *addr);
        int test_and_change_bit(unsigned long nr, volatile unsigned long *addr);


> In your above examples, I think you probably want full smp_mb() there
> because you do want to prevent loads inside the critical section from
> being completed before the bit is visible or after the bit is cleared.

bit_spin_unlock() does smp_mb__before_clear_bit() which would also be
enough, since on the wacky platforms that equals smp_mb().

Nitin, it looks like the current code would indeed be correct, sorry for
the noise.

Thanks Nick.

Re: [lc-devel] Announce: Compressed cache alpha-007 (kernel 2.6.18)

[Nick P. <np...@su...>]

On Wed, Sep 20, 2006 at 04:39:45PM +0200, Peter Zijlstra wrote:
> On Wed, 2006-09-20 at 19:34 +0530, Nitin Gupta wrote:
> > Peter Zijlstra wrote:
> > > On Wed, 2006-09-20 at 18:23 +0530, Nitin Gupta wrote:
> > > 
> > >>> Don't like the bit_spin_trylock/bit_spin_unlock in handle_ccache_fault;
> > >>> what's wrong with TestSetPageLocked() and unlock_page() ?
> > >>>
> > >> If (PageCompressed(page)) is true then 'page' is 'struct chunk_head'
> > >> not 'struct page' and you cannot use unlock_page() on chunk_head.
> > > 
> > > ClearPageLocked()
> > > 
> > 
> > But then how will you do equivalent of wait_on_chunk_head() ?
> 
> Doh, now I see, its not &page->flags but &ch->flags.
> 
> Humm, you'd need to open code this I think, bit_spin_trylock() may not
> be ordered strong enough (on !x86). Got my head in a twist, but I think
> this is correct:
> 
> static inline
> int chunk_head_trylock(struct chunk_head *ch)
> {
> 	int locked = test_set_bit(PG_locked, &ch->flags);
> 	if (!locked)
> 		smb_wmb();
> 	return !locked;
> }
> 
> static inline
> void chunk_head_unlock(struct chunk_head *ch)
> {
> 	int locked;
> 	smp_wmb();
> 	locked = test_clear_bit(PG_locked, &ch->flags);
> 	BUG_ON(!locked);
> }

A plain clear_bit(PG_locked, ...) here will leak, but all atomic and
bitop RMW ops are defined to be strongly ordered before and after (by
Documentation/atomic_ops.txt), so I think we're OK?

In your above examples, I think you probably want full smp_mb() there
because you do want to prevent loads inside the critical section from
being completed before the bit is visible or after the bit is cleared.

Nick

Re: [lc-devel] Announce: Compressed cache alpha-007 (kernel 2.6.18)

[Peter Z. <a.p...@ch...>]

On Wed, 2006-09-20 at 19:34 +0530, Nitin Gupta wrote:
> Peter Zijlstra wrote:
> > On Wed, 2006-09-20 at 18:23 +0530, Nitin Gupta wrote:
> > 
> >>> Don't like the bit_spin_trylock/bit_spin_unlock in handle_ccache_fault;
> >>> what's wrong with TestSetPageLocked() and unlock_page() ?
> >>>
> >> If (PageCompressed(page)) is true then 'page' is 'struct chunk_head'
> >> not 'struct page' and you cannot use unlock_page() on chunk_head.
> > 
> > ClearPageLocked()
> > 
> 
> But then how will you do equivalent of wait_on_chunk_head() ?

Doh, now I see, its not &page->flags but &ch->flags.

Humm, you'd need to open code this I think, bit_spin_trylock() may not
be ordered strong enough (on !x86). Got my head in a twist, but I think
this is correct:

static inline
int chunk_head_trylock(struct chunk_head *ch)
{
	int locked = test_set_bit(PG_locked, &ch->flags);
	if (!locked)
		smb_wmb();
	return !locked;
}

static inline
void chunk_head_unlock(struct chunk_head *ch)
{
	int locked;
	smp_wmb();
	locked = test_clear_bit(PG_locked, &ch->flags);
	BUG_ON(!locked);
}

static inline
int chunk_head_wait(struct chunk_head *ch)
{
	while (test_bit(PG_locked, &ch->flags))
		relax_cpu();
	smp_rmb();
}

Re: [lc-devel] Announce: Compressed cache alpha-007 (kernel 2.6.18)

[Nitin G. <nit...@gm...>]

Nitin Gupta wrote:
> Peter Zijlstra wrote:
>> On Wed, 2006-09-20 at 18:23 +0530, Nitin Gupta wrote:
>>
>>>> Don't like the bit_spin_trylock/bit_spin_unlock in handle_ccache_fault;
>>>> what's wrong with TestSetPageLocked() and unlock_page() ?
>>>>
>>> If (PageCompressed(page)) is true then 'page' is 'struct chunk_head'
>>> not 'struct page' and you cannot use unlock_page() on chunk_head.
>>
>> ClearPageLocked()
>>
> 
> But then how will you do equivalent of wait_on_chunk_head() ?
> 
Please ignore above strange reply.

I meant:
bit_spin_trylock() -> TestSetPageLocked()
bit_spin_unlock() -> ClearPageLocked()

didn't seem correct to me. Like, isn't smb_mb_etc..() done by 
bit_spin_unlock() required on SMP?

-- Nitin

Re: [lc-devel] Announce: Compressed cache alpha-007 (kernel 2.6.18)

[Nitin G. <nit...@gm...>]

Peter Zijlstra wrote:
> On Wed, 2006-09-20 at 18:23 +0530, Nitin Gupta wrote:
> 
>>> Don't like the bit_spin_trylock/bit_spin_unlock in handle_ccache_fault;
>>> what's wrong with TestSetPageLocked() and unlock_page() ?
>>>
>> If (PageCompressed(page)) is true then 'page' is 'struct chunk_head'
>> not 'struct page' and you cannot use unlock_page() on chunk_head.
> 
> ClearPageLocked()
> 

But then how will you do equivalent of wait_on_chunk_head() ?

-- Nitin

Re: [lc-devel] Announce: Compressed cache alpha-007 (kernel 2.6.18)

[Peter Z. <a.p...@ch...>]

On Wed, 2006-09-20 at 18:23 +0530, Nitin Gupta wrote:

> >
> > +       /*
> > +        * This allocation must never sleep and must never fail.
> > +        * -- Doing GFP_ATOMIC will guarantee that I doesn't sleep
> > +        * but alloc may fail!
> > +        * -- Doing GFP_KERNEL giver higher chances that alloc will
> > +        * be successfull but it may sleep (and hence doesn't work)!
> > +        * -- What to do??
> > +        */
> > +       comp_page = alloc_page(GFP_ATOMIC);
> >
> > unsigned long pflags = current->flags;
> > current->flags |= PF_MEMALLOC;
> > alloc_page(GFP_NOWAIT);
> > current->flags = pflags;
> >
> A dumb question: IIRC 'current' points to currently executing task?
> What if 'current' changes between these statements -- any locking
> required to prevent this (like disable irq to keep 'current' current)?

current cannot change from the point of view of the execution thread.

> > or steal my __GFP_EMERGENCY patch.
> >
> It's in mainline now? or plan to be mainlined soon?

Not in mainline, I hope to get it there, but not looking to bright atm.
But that is mainly the rest of the patches, the __GFP_EMERGENCY
bit looks like so:

Index: linux-2.6/include/linux/gfp.h
===================================================================
--- linux-2.6.orig/include/linux/gfp.h
+++ linux-2.6/include/linux/gfp.h
@@ -46,6 +46,7 @@ struct vm_area_struct;
 #define __GFP_ZERO	((__force gfp_t)0x8000u)/* Return zeroed page on success */
 #define __GFP_NOMEMALLOC ((__force gfp_t)0x10000u) /* Don't use emergency reserves */
 #define __GFP_HARDWALL   ((__force gfp_t)0x20000u) /* Enforce hardwall cpuset memory allocs */
+#define __GFP_EMERGENCY  ((__force gfp_t)0x40000u) /* Use emergency reserves */
 
 #define __GFP_BITS_SHIFT 20	/* Room for 20 __GFP_FOO bits */
 #define __GFP_BITS_MASK ((__force gfp_t)((1 << __GFP_BITS_SHIFT) - 1))
@@ -54,7 +55,7 @@ struct vm_area_struct;
 #define GFP_LEVEL_MASK (__GFP_WAIT|__GFP_HIGH|__GFP_IO|__GFP_FS| \
 			__GFP_COLD|__GFP_NOWARN|__GFP_REPEAT| \
 			__GFP_NOFAIL|__GFP_NORETRY|__GFP_NO_GROW|__GFP_COMP| \
-			__GFP_NOMEMALLOC|__GFP_HARDWALL)
+			__GFP_NOMEMALLOC|__GFP_HARDWALL|__GFP_EMERGENCY)
 
 /* This equals 0, but use constants in case they ever change */
 #define GFP_NOWAIT	(GFP_ATOMIC & ~__GFP_HIGH)
Index: linux-2.6/mm/page_alloc.c
===================================================================
--- linux-2.6.orig/mm/page_alloc.c
+++ linux-2.6/mm/page_alloc.c
@@ -971,8 +972,8 @@ restart:
 
 	/* This allocation should allow future memory freeing. */
 
-	if (((p->flags & PF_MEMALLOC) || unlikely(test_thread_flag(TIF_MEMDIE)))
-			&& !in_interrupt()) {
+	if ((((p->flags & PF_MEMALLOC) || unlikely(test_thread_flag(TIF_MEMDIE)))
+			&& !in_interrupt()) || (gfp_mask & __GFP_EMERGENCY)) {
 		if (!(gfp_mask & __GFP_NOMEMALLOC)) {
 nofail_alloc:
 			/* go through the zonelist yet again, ignoring mins */

> > +       tmp_page = alloc_pages(GFP_KERNEL, 1);  /* page may expand */
> >
> > 1 order alloc? No way to not do that? Compression will fail if you don't
> > provide enough output space, right? perhaps just discard the page,
> > negative savings just don't make sense.
> >
> Yes. 1 order alloc!! A failure point for ccache. The pages that expand
> are already discarded but problem is to provide temporary buffer to
> get compressed output in first place. Alternate is to insert size
> checks within compressor tight loop -- even this seemed hard in
> strange LZO code.

Ah, so the compressor requires it, too bad. Then perhaps preallocate a
few 1-order pages; if you could ensure the max concurrency to be NR_CPUS
that would be great, otherwise you'd have to stick in a fallback path.

> > Also:
> >
> > +struct chunk {
> > +       void *start_addr;       /* page addr + offset within page
> > +                                * where chunk starts */
> > +       unsigned short size;    /* size: 12 LSB bits, flags: rest 4 bits */
> > +       struct chunk *next;     /* link to next 'related' chunk */
> > +       struct list_head chunks;        /* 'master chunk list': every
> > +                                        * chunk is linked */
> > +};
> >
> > that unsigned short is a waste, the compiler will align the next field
> > to 32 bit anyway (unless you add the packed attribute to the struct) and
> > the size of struct chunk would be 20 bytes and struct chunk is
> > kmalloc'ed and the smallest slab is 32 bytes, so you waste heaps of
> > memory here, just be clear and don't fiddle with bitfields, it doesn't
> > gain you anything.
> >
> 
> So, there's no way to allocate just 20 bytes? I need to keep this
> struct as small as possible. 32 bytes will be too much for stuct
> chunk! Declaring it as packed and then kmalloc() will still use
> 32-bytes. right?

yep, you could perhaps declare your own slab (kmem_cache) for this
purpose (not quite sure on the slab size restrictions, it might be that
32 is actually the smallest possible). (if you do pack it, put the short
at the end, that way the rest will stay aligned)

Either that, or embed struct chunk within the actual data space.

> > Don't like the bit_spin_trylock/bit_spin_unlock in handle_ccache_fault;
> > what's wrong with TestSetPageLocked() and unlock_page() ?
> >
> 
> If (PageCompressed(page)) is true then 'page' is 'struct chunk_head'
> not 'struct page' and you cannot use unlock_page() on chunk_head.

ClearPageLocked()

> > PageWillCompress() doesn't look necessary, can't you just add a
> > parameter to pageout() instead?
> >
> hm...PageWillCompress() will now disappear :)

goodness, :-)

> > Why not make ccache a proper address_space and modify do_swap_page()
> > that should get rid of a lot of the intrusiveness in the find_get_page()
> > family. Of course that would mean finding another bit in the swp_entry_t
> > (perhaps you can use some of the page_migration bits and make ccache and
> > page migration mutually exclusive).
> >
> 
> This would make it hard to handle page-cache pages. So, these
> intrusive changes in 4-5 lookup functions looked better to me....

Right, pinning the file's address_space will be hard,.. /me goes think
on it.

Re: [lc-devel] Announce: Compressed cache alpha-007 (kernel 2.6.18)

[Nitin G. <nit...@gm...>]

On 9/20/06, Peter Zijlstra <a.p...@ch...> wrote:
> On Wed, 2006-09-20 at 14:38 +0530, Nitin Gupta wrote:
> > ------------
> > Project: Compressed Caching for Linux
> > Project Home: http://linuxcompressed.sourceforge.net
> > Git (web): http://dev.laptop.org/git.do?p=projects/linux-mm-cc
> > Git (git): git://dev.laptop.org/projects/linux-mm-cc
> > ------------
> >
> > Hi!
> >
> > This patch has significantly changed locking scheme in
> > lookup functions. This was to solve race problems which
> > surfaced while testing on SMP system.
> >
> > [Patch download]:
> > http://prdownloads.sourceforge.net/linuxcompressed/patch-ccache-alpha-007-2.6.18?download
> >
<snip>

> Wasn't there some effort to stick LZO into the crypto API?
>
I'm not aware of that.

> Also, I think the consensus on including sources like that is to clean
> up the sources as much as possible; eg.
>  #ifdef __cplusplus
> is a no go. Also the LZO source is riddled with ifdeffery.
>
> See the thread here:
>   http://lkml.org/lkml/2006/8/26/96
>

Yes. Cleaning up LZO is in my TODO. Already removed several KLOC of
ifdeffery. It is extreme pain to cleanup and port to kernel space the
original LZO code.


> Perhaps use the LZF crypto API patches from suspend2?
>
I will look into this.


> Could you, for the next version, please split this huge patch into
> pieces, for example like so:
>
>   add LZO compressor
>   add WK compressor
>   add ccache core
>   add bits and pieces to glue ccache into kernel
>
> the LZO/WK code in the current patch is huge and that pretty much
> clutters it for readability.
>
> This too would make commenting easier, since you'd them be able to post
> the patches inline.

Sure. will do this for next patch.

>
> @@ -117,6 +117,7 @@ enum {
>         SWP_ACTIVE      = (SWP_USED | SWP_WRITEOK),
>                                         /* add others here before... */
>         SWP_SCANNING    = (1 << 8),     /* refcount in scan_swap_map */
> +       SWP_COMPRESSED  = (1 << 10),    /* it's compressed cache for anon pages */
>  };
>
> I think you missed the 'add others here before...' comment, you're now
> stomping onto the swap scan counter space.
>
Yes -- missed it :) Will make it (1<<2).

> For ccache.c; could you stick all those globals into a struct? That
> reads nicer.

ok. will group them under struct(s).

> Also, no need to assign 0 to statics.

ok.

>
> +       /*
> +        * This allocation must never sleep and must never fail.
> +        * -- Doing GFP_ATOMIC will guarantee that I doesn't sleep
> +        * but alloc may fail!
> +        * -- Doing GFP_KERNEL giver higher chances that alloc will
> +        * be successfull but it may sleep (and hence doesn't work)!
> +        * -- What to do??
> +        */
> +       comp_page = alloc_page(GFP_ATOMIC);
>
> unsigned long pflags = current->flags;
> current->flags |= PF_MEMALLOC;
> alloc_page(GFP_NOWAIT);
> current->flags = pflags;
>
A dumb question: IIRC 'current' points to currently executing task?
What if 'current' changes between these statements -- any locking
required to prevent this (like disable irq to keep 'current' current)?

> or steal my __GFP_EMERGENCY patch.
>
It's in mainline now? or plan to be mainlined soon?

> +       tmp_page = alloc_pages(GFP_KERNEL, 1);  /* page may expand */
>
> 1 order alloc? No way to not do that? Compression will fail if you don't
> provide enough output space, right? perhaps just discard the page,
> negative savings just don't make sense.
>
Yes. 1 order alloc!! A failure point for ccache. The pages that expand
are already discarded but problem is to provide temporary buffer to
get compressed output in first place. Alternate is to insert size
checks within compressor tight loop -- even this seemed hard in
strange LZO code.

> BTW, what's the deal with these chunks? is that a sort of heap allocator
> on top of the page allocator, and then link enough chunks to find all
> data again?

Yes. Store a single compressed page scattered over many physical pages
and track each of these 'chunks' by keeping their start address and
size (struct chunk).

>
> Can't you pull that out and abstract that? It will be another patch in
> the series, and you might end up with cleaner code.
>
Abstracting this seems good -- will try this.

> Also, merge_chunk() why does it loop, if you look for adjacent chunks on
> free, you can only ever find 1 before and 1 after.
>
It does not loop. It just looks 1 fwd and then 1 backward and then
returns. Will cleanup this function so it becomes clearer.

> Also:
>
> +struct chunk {
> +       void *start_addr;       /* page addr + offset within page
> +                                * where chunk starts */
> +       unsigned short size;    /* size: 12 LSB bits, flags: rest 4 bits */
> +       struct chunk *next;     /* link to next 'related' chunk */
> +       struct list_head chunks;        /* 'master chunk list': every
> +                                        * chunk is linked */
> +};
>
> that unsigned short is a waste, the compiler will align the next field
> to 32 bit anyway (unless you add the packed attribute to the struct) and
> the size of struct chunk would be 20 bytes and struct chunk is
> kmalloc'ed and the smallest slab is 32 bytes, so you waste heaps of
> memory here, just be clear and don't fiddle with bitfields, it doesn't
> gain you anything.
>

So, there's no way to allocate just 20 bytes? I need to keep this
struct as small as possible. 32 bytes will be too much for stuct
chunk! Declaring it as packed and then kmalloc() will still use
32-bytes. right?

> Don't like the bit_spin_trylock/bit_spin_unlock in handle_ccache_fault;
> what's wrong with TestSetPageLocked() and unlock_page() ?
>

If (PageCompressed(page)) is true then 'page' is 'struct chunk_head'
not 'struct page' and you cannot use unlock_page() on chunk_head.

> you have duplicated the radix_tree_loockup in handle_ccache_fault(), you
> can easily unify those two.
>
Yes! I see now. I will do that :)

> PageWillCompress() doesn't look necessary, can't you just add a
> parameter to pageout() instead?
>
hm...PageWillCompress() will now disappear :)

> Why not make ccache a proper address_space and modify do_swap_page()
> that should get rid of a lot of the intrusiveness in the find_get_page()
> family. Of course that would mean finding another bit in the swp_entry_t
> (perhaps you can use some of the page_migration bits and make ccache and
> page migration mutually exclusive).
>

This would make it hard to handle page-cache pages. So, these
intrusive changes in 4-5 lookup functions looked better to me....


Thanks for reviewing the patch!  :)


Cheers,
Nitin

Re: [lc-devel] Announce: Compressed cache alpha-007 (kernel 2.6.18)

[Peter Z. <a.p...@ch...>]

On Wed, 2006-09-20 at 14:38 +0530, Nitin Gupta wrote:
> ------------
> Project: Compressed Caching for Linux
> Project Home: http://linuxcompressed.sourceforge.net
> Git (web): http://dev.laptop.org/git.do?p=projects/linux-mm-cc
> Git (git): git://dev.laptop.org/projects/linux-mm-cc
> ------------
> 
> Hi!
> 
> This patch has significantly changed locking scheme in
> lookup functions. This was to solve race problems which
> surfaced while testing on SMP system.
> 
> [Patch download]:
> http://prdownloads.sourceforge.net/linuxcompressed/patch-ccache-alpha-007-2.6.18?download
> 
> I tested this patch on 32-bit system Only with 10M for
> page-cache and 5M for swap-cache (RAM: 128M).
> 
> I think, porting compression algos. to 64-bit is all thats
> needed for 64-bit ccache support. Please mail me
> (or mailing list) if you are interested in this.
> 
> It will be great help if anyone can please provide
> code review for this patch :)
> 
> 
> * Changelog: ccache-alpha-007 (applies to 2.6.18)
> 
> Changes since ccahe-alpha-006
> -- Major locking changes in lookup functions.
> -- Fixed chunk_head usage count which could lead to 'double free'
> -- Removed abt. 500 LOC.

Wasn't there some effort to stick LZO into the crypto API?

Also, I think the consensus on including sources like that is to clean
up the sources as much as possible; eg. 
 #ifdef __cplusplus 
is a no go. Also the LZO source is riddled with ifdeffery.

See the thread here:
  http://lkml.org/lkml/2006/8/26/96

Perhaps use the LZF crypto API patches from suspend2?

Could you, for the next version, please split this huge patch into
pieces, for example like so:

  add LZO compressor
  add WK compressor
  add ccache core
  add bits and pieces to glue ccache into kernel

the LZO/WK code in the current patch is huge and that pretty much
clutters it for readability.

This too would make commenting easier, since you'd them be able to post
the patches inline.

@@ -117,6 +117,7 @@ enum {
 	SWP_ACTIVE	= (SWP_USED | SWP_WRITEOK),
 					/* add others here before... */
 	SWP_SCANNING	= (1 << 8),	/* refcount in scan_swap_map */
+	SWP_COMPRESSED	= (1 << 10),	/* it's compressed cache for anon pages */
 };

I think you missed the 'add others here before...' comment, you're now
stomping onto the swap scan counter space.

For ccache.c; could you stick all those globals into a struct? That
reads nicer. Also, no need to assign 0 to statics.

+	/*
+	 * This allocation must never sleep and must never fail.
+	 * -- Doing GFP_ATOMIC will guarantee that I doesn't sleep
+	 * but alloc may fail!
+	 * -- Doing GFP_KERNEL giver higher chances that alloc will
+	 * be successfull but it may sleep (and hence doesn't work)!
+	 * -- What to do??
+	 */
+	comp_page = alloc_page(GFP_ATOMIC);

unsigned long pflags = current->flags;
current->flags |= PF_MEMALLOC;
alloc_page(GFP_NOWAIT);
current->flags = pflags;

or steal my __GFP_EMERGENCY patch.

+	tmp_page = alloc_pages(GFP_KERNEL, 1);	/* page may expand */

1 order alloc? No way to not do that? Compression will fail if you don't
provide enough output space, right? perhaps just discard the page,
negative savings just don't make sense.

BTW, what's the deal with these chunks? is that a sort of heap allocator
on top of the page allocator, and then link enough chunks to find all
data again?

Can't you pull that out and abstract that? It will be another patch in
the series, and you might end up with cleaner code.

Also, merge_chunk() why does it loop, if you look for adjacent chunks on
free, you can only ever find 1 before and 1 after.

Also:

+struct chunk {
+	void *start_addr;	/* page addr + offset within page
+				 * where chunk starts */
+	unsigned short size;	/* size: 12 LSB bits, flags: rest 4 bits */
+	struct chunk *next;	/* link to next 'related' chunk */
+	struct list_head chunks;	/* 'master chunk list': every
+					 * chunk is linked */
+};

that unsigned short is a waste, the compiler will align the next field
to 32 bit anyway (unless you add the packed attribute to the struct) and
the size of struct chunk would be 20 bytes and struct chunk is
kmalloc'ed and the smallest slab is 32 bytes, so you waste heaps of
memory here, just be clear and don't fiddle with bitfields, it doesn't
gain you anything.

Don't like the bit_spin_trylock/bit_spin_unlock in handle_ccache_fault;
what's wrong with TestSetPageLocked() and unlock_page() ?

you have duplicated the radix_tree_loockup in handle_ccache_fault(), you
can easily unify those two.

PageWillCompress() doesn't look necessary, can't you just add a
parameter to pageout() instead?

Why not make ccache a proper address_space and modify do_swap_page()
that should get rid of a lot of the intrusiveness in the find_get_page()
family. Of course that would mean finding another bit in the swp_entry_t
(perhaps you can use some of the page_migration bits and make ccache and
page migration mutually exclusive).

[lc-devel] Announce: Compressed cache alpha-007 (kernel 2.6.18)

[Nitin G. <nit...@gm...>]

------------
Project: Compressed Caching for Linux
Project Home: http://linuxcompressed.sourceforge.net
Git (web): http://dev.laptop.org/git.do?p=projects/linux-mm-cc
Git (git): git://dev.laptop.org/projects/linux-mm-cc
------------

Hi!

This patch has significantly changed locking scheme in
lookup functions. This was to solve race problems which
surfaced while testing on SMP system.

[Patch download]:
http://prdownloads.sourceforge.net/linuxcompressed/patch-ccache-alpha-007-2.6.18?download

I tested this patch on 32-bit system Only with 10M for
page-cache and 5M for swap-cache (RAM: 128M).

I think, porting compression algos. to 64-bit is all thats
needed for 64-bit ccache support. Please mail me
(or mailing list) if you are interested in this.

It will be great help if anyone can please provide
code review for this patch :)


* Changelog: ccache-alpha-007 (applies to 2.6.18)

Changes since ccahe-alpha-006
-- Major locking changes in lookup functions.
-- Fixed chunk_head usage count which could lead to 'double free'
-- Removed abt. 500 LOC.


Cheers,
Nitin

[lc-devel] Problems with ccache

[Nitin G. <nit...@gm...>]

Hi All,

Some project news...

-- Major cleanups done and >1KLOC removed! and bug fixes (major fix: page-cache
 compression stopped once max_fs_backed_cc_size limit was reached for first
time). This new patch posted as: patch-ccache-alpha-006-2.6.18-rc6-git3.

http://prdownloads.sourceforge.net/linuxcompressed/patch-ccache-alpha-006-2.6.18-rc6-git3?download

-- Also done tests with this new patch on (virtual) SMP (2-x86) and this
revealed locking problems in find_get_pages() and friends (though locking in
find_get_page() looks fine). Though I now know races that exist in this
function (truncate happens during we release tree_lock) but have no immediate
solution to the problem and working to get it right :)

-----------------------------------------------------

Here's BUG I get during tests:

 BUG: unable to handle kernel NULL pointer dereference at virtual address
00000000
  printing eip:
 c014aa1e
 *pde = 04e3c067
 *pte = 00000000
 Oops: 0000 [#1]
 PREEMPT SMP
 Modules linked in: floppy nvram usblp uhci_hcd sg pcnet32 pcspkr mii BusLogic
sd_mod scsi_mod
 CPU:    1
 EIP:    0060:[<c014aa1e>]    Not tainted VLI
 EFLAGS: 00210097   (2.6.18-rc6-cc #120)
 EIP is at find_get_pages+0x58/0xf2
 eax: 00000000   ebx: c7c91ea0   ecx: c7fc0a90   edx: 00000000
 esi: c7fc0de0   edi: 00000008   ebp: c7c91e68   esp: c7c91e44
 ds: 007b   es: 007b   ss: 0068
 Process kswapd0 (pid: 94, ti=c7c90000 task=c7fc0a90 task.ti=c7c90000)
 Stack: c02fc633 c02e2f89 80010008 c4523dc0 c4523c00 00000001 00000000 c7c91e94
        00000000 c7c91e7c c014f53b c7c91e9c 00000080 c4523c90 c7c91c36 c014fd4f
        0000000e ffffffff c4523db0 00000000 00000000 00000000 c1088f00 00000000
 Call Trace:
  [<c014f53b>] pagevec_lookup+0x1e/0x27
  [<c014fd4f>] isolate_lru_pages+0x1f/0xce
 DWARF2 unwinder stuck at isolate_lru_pages+0x1f/0xce
 Leftover inexact backtrace:
  [<c01040a1>] show_stack_log_lvl+0xa6/0xcb
  [<c0104294>] show_registers+0x1ce/0x259
  [<c0104450>] die+0x131/0x2e7
  [<c02dd75b>] do_page_fault+0x1fb/0x5f0
  [<c01039d9>] error_code+0x39/0x40
  [<c014f53b>] pagevec_lookup+0x1e/0x27
  [<c014fd4f>] isolate_lru_pages+0x1f/0xce
  [<00010000>] 0x10000
 Code: 0f 09 00 89 45 f0 85 c0 0f 84 9c 00 00 00 89 fb 31 ff eb 0f 83 c7 01 83
c3 04 39 7d f0 0f 84 87 00 00 00 8b 33 8b 06 89 03 89 c2 <8b> 00 f6 c4 40 0f 85
87 00 00 00 f0 ff 42 04 8b 13 8b 02 a9 00

-----------------

Please mail any solution/comment you have. Happy Hacking! :)

Cheers,
Nitin

Re: [lc-devel] [linux-mm-cc] Announce: Compressed cache alpha-005 release

[Allan B. <all...@gm...>]

Hi Nitin and all,

I tested alpha-005 on a ARM based arch and it didn't crash. The tests had
been similar to Nitin use case.

* I tested this as:
RAM: 64MB
ccache for anon pages - size: 2.5MB (640 pages)
ccache for page cache pages - size: 5MB (1280 pages)

I'll do more tests and will send the results to list soon.

Regards,

Allan Bezerra


On 9/5/06, Nitin Gupta <nit...@gm...> wrote:
>
> ------------
> Project: Compressed Caching for Linux (2.6.x kernels)
> Git (web): http://dev.laptop.org/git.do?p=projects/linux-mm-cc
> Git (git): git://dev.laptop.org/projects/linux-mm-cc
> Home Page: http://linuxcompressed.sourceforge.net
> ------------
>
>
> Hi all!
>
> This release brings a Major new addition to compressed caching
> feature (kernel 2.6.18-rc6) -- Now, both page-cache (clean &
> dirty) pages and swap-cache pages are compressed!
>
> Also fixed a lot of other bugs!
>
>
> * Usage:
> It creates two /proc entries:
> /proc/sys/vm/{max_anon_cc_size,max_fs_backed_cc_size}
>
> Use these to set compressed cache size (in unit of no. of
> pages) for anonymous(swap-cache) and
> filesystem-backed(page-cache) pages respectively.
>
>
> * I tested this as:
> RAM: 128MB
> ccache for anon pages - size: 5MB (1280 pages)
> ccache for page cache pages - size: 10MB (2560 pages)
>
> Launched openoffice-writer, gimp, firefox, kate, konsole. Closed
> these, re-opened, open some web-pages, some file in writer,
> close all, open all again --- it didn't crash on _my_ system.
> (Focusing on correctness for now!)
>
> If you test it and find _any_ problems, please mail me or on
> mailing list. Thanks!
>
>
> * NOTES
> -- page-cache and swap-cache compression can be separately
> turned on. So, you can do separate tests for these by keeping
> other to 0 size.
>
> -- Page-cache pages that could now be added to ccache are let
> goto disks (or simply freed for clean pages).
>
> -- Pages are cyclically compressed using WKdm, WK4x4 and LZO.
> You can easily change this behavior by changing single line in
> guess_algo() in mm/ccache.c (see function comments).
>
> -- You can further filter (like allowing only dirty page
> cache pages) which pages are compressed by simply adding
> criteria in should_add_to_ccache() in mm/ccache.c
>
>
> * TODO
> -- Export statistics like current anon and file-system backed
> ccache sizes (_whatever_ statistics are required to get useful
> benchmark figures).
>
> -- Analyze more properly conditions of _very_ low memory
> conditions like what happens if OOM killer kills a process
> whose pages are being compressed!
>
> -- Write in detail what exactly remains, present problems: also
> list requirements for long term goals like dynamic ccache
> resizing support.
>
> -- Code cleanups: like use proper log level for info/warning or
> debug messages. Don't use pr_info() throughout.
>
>
> If you test it please mail me the results! Thanks!
>
>
> * Patch (for kernel 2.6.18-rc6):
> http://prdownloads.sourceforge.net/linuxcompressed/patch-ccache-
> alpha-005-2.6.18-rc6?download
>
>
> Cheers,
> Nitin
> _______________________________________________
> linux-mm-cc mailing list
> lin...@la...
> http://mailman.laptop.org/mailman/listinfo/linux-mm-cc
>

[lc-devel] Announce: Compressed cache alpha-005 release

[Nitin G. <nit...@gm...>]

------------
Project: Compressed Caching for Linux (2.6.x kernels)
Git (web): http://dev.laptop.org/git.do?p=projects/linux-mm-cc
Git (git): git://dev.laptop.org/projects/linux-mm-cc
Home Page: http://linuxcompressed.sourceforge.net
------------


Hi all!

This release brings a Major new addition to compressed caching
feature (kernel 2.6.18-rc6) -- Now, both page-cache (clean &
dirty) pages and swap-cache pages are compressed!

Also fixed a lot of other bugs!


* Usage:
It creates two /proc entries:
/proc/sys/vm/{max_anon_cc_size,max_fs_backed_cc_size}

Use these to set compressed cache size (in unit of no. of
pages) for anonymous(swap-cache) and
filesystem-backed(page-cache) pages respectively.


* I tested this as:
RAM: 128MB
ccache for anon pages - size: 5MB (1280 pages)
ccache for page cache pages - size: 10MB (2560 pages)

Launched openoffice-writer, gimp, firefox, kate, konsole. Closed
these, re-opened, open some web-pages, some file in writer,
close all, open all again --- it didn't crash on _my_ system.
(Focusing on correctness for now!)

If you test it and find _any_ problems, please mail me or on
mailing list. Thanks!


* NOTES
-- page-cache and swap-cache compression can be separately
turned on. So, you can do separate tests for these by keeping
other to 0 size.

-- Page-cache pages that could now be added to ccache are let
goto disks (or simply freed for clean pages).

-- Pages are cyclically compressed using WKdm, WK4x4 and LZO.
You can easily change this behavior by changing single line in
guess_algo() in mm/ccache.c (see function comments).

-- You can further filter (like allowing only dirty page
cache pages) which pages are compressed by simply adding
criteria in should_add_to_ccache() in mm/ccache.c


* TODO
-- Export statistics like current anon and file-system backed
ccache sizes (_whatever_ statistics are required to get useful
benchmark figures).

-- Analyze more properly conditions of _very_ low memory
conditions like what happens if OOM killer kills a process
whose pages are being compressed!

-- Write in detail what exactly remains, present problems: also
list requirements for long term goals like dynamic ccache
resizing support.

-- Code cleanups: like use proper log level for info/warning or
debug messages. Don't use pr_info() throughout.


If you test it please mail me the results! Thanks!


* Patch (for kernel 2.6.18-rc6):
http://prdownloads.sourceforge.net/linuxcompressed/patch-ccache-
alpha-005-2.6.18-rc6?download


Cheers,
Nitin

Re: [lc-devel] Some testings using ccache pre-alpha 003 for i386

[Anderson B. <bri...@gm...>]

Hi all (again!),

A small correction: the kernel used  was linus kernel 2.6.18-rc4 with
ccache alpha 004.

Cheers,

Anderson Briglia

On 8/29/06, Anderson Briglia <bri...@gm...> wrote:
> Hi all,
>
> On 8/29/06, Anderson Briglia <bri...@gm...> wrote:
> > Hi all,
> >
> > I did a quick test with the pre-alpha 004 and fillmem. Using a larger
> > ccache, we can improve the test's speed. (see file attached). This
> > version seems to be more stable and "workable" on a real environment.
> > :-)
>
> Just to add:
> - I used fillmem 40 (MB)
> - And a ccache size of 2500 pages (or 10MB)
> - linus kernel 2.6.18-rc4 with ccache pre-alpha 003 applied
> - qemu with ubuntu-dapper image
> - 128MB of RAM
> - No Swap devices
> - After every test, the machine was rebooted
>
> > Actually we need a testing use case that is able to show the ccache
> > benefits with anon pages.
> > AFAIK, this ccache version was designed to improve the memory
> > consumption, postponing the OOM killer call, for instance. So, we need
> > a test use case that evaluates this.
> >
> > Best regards,
> >
> > Anderson Briglia
> >
> >
> > On 8/28/06, Nitin Gupta <nit...@gm...> wrote:
> > > Hi,
> > >
> > > Please see new page posted on project home page:
> > > http://linuxcompressed.sourceforge.net/braindumps
> > > I have detailed here possible explanation for these negative results.
> > >
> > > I hope to have some solutions implemented soon :)
> > >
>
> <snip>
>

Re: [lc-devel] Some testings using ccache pre-alpha 003 for i386

[Anderson B. <bri...@gm...>]

Hi all,

On 8/29/06, Anderson Briglia <bri...@gm...> wrote:
> Hi all,
>
> I did a quick test with the pre-alpha 004 and fillmem. Using a larger
> ccache, we can improve the test's speed. (see file attached). This
> version seems to be more stable and "workable" on a real environment.
> :-)

Just to add:
- I used fillmem 40 (MB)
- And a ccache size of 2500 pages (or 10MB)
- linus kernel 2.6.18-rc4 with ccache pre-alpha 003 applied
- qemu with ubuntu-dapper image
- 128MB of RAM
- No Swap devices
- After every test, the machine was rebooted

> Actually we need a testing use case that is able to show the ccache
> benefits with anon pages.
> AFAIK, this ccache version was designed to improve the memory
> consumption, postponing the OOM killer call, for instance. So, we need
> a test use case that evaluates this.
>
> Best regards,
>
> Anderson Briglia
>
>
> On 8/28/06, Nitin Gupta <nit...@gm...> wrote:
> > Hi,
> >
> > Please see new page posted on project home page:
> > http://linuxcompressed.sourceforge.net/braindumps
> > I have detailed here possible explanation for these negative results.
> >
> > I hope to have some solutions implemented soon :)
> >

<snip>

Re: [lc-devel] Some testings using ccache pre-alpha 003 for i386

[Anderson B. <bri...@gm...>]

Hi all,

I did a quick test with the pre-alpha 004 and fillmem. Using a larger
ccache, we can improve the test's speed. (see file attached). This
version seems to be more stable and "workable" on a real environment.
:-)
Actually we need a testing use case that is able to show the ccache
benefits with anon pages.
AFAIK, this ccache version was designed to improve the memory
consumption, postponing the OOM killer call, for instance. So, we need
a test use case that evaluates this.

Best regards,

Anderson Briglia


On 8/28/06, Nitin Gupta <nit...@gm...> wrote:
> Hi,
>
> Please see new page posted on project home page:
> http://linuxcompressed.sourceforge.net/braindumps
> I have detailed here possible explanation for these negative results.
>
> I hope to have some solutions implemented soon :)
>
> Cheers,
> Nitin
>
>
> Anderson Briglia wrote:
> > Hi all,
> >
> > I did some tests using the latest ccache code posted by Nitin Gupta. I
> > divided the tests in two types: Memory behavior and time performance.
> > All tests had this scenario:
> >
> > - linus kernel 2.6.18-rc4 with ccache pre-alpha 003 applied
> > - qemu with ubuntu-dapper image
> > - 128MB of RAM
> > - No Swap devices
> > - After every test, the machine was rebooted
> >
> > Memory Behavior
> > -----------------------------------------------------------
> > This test intends to evaluate what happens on the system when it has a
> > high memory load. What is the ccache impact? Is it stable even the
> > free memory is critical low?
> > To do this test I used memtest 0.0.4 [1], that is a suite of tests
> > developed to evaluate the stability and consistency of the Linux
> > memory management system. It is composed of some testing programs but
> > I used just one test, called fillmem. Fillmem tests the memory
> > allocation system. It is useful to check the virtual memory system
> > face allocation memory, pagination and swap usage. As its parameter,
> > fillmem receives the size of the memory that will be allocated.
> >
> > fillmem50-ccache1000.gif (graph01) attached file represents the memory
> > when executed fillmem with 50MB of parameter and ccache with 1000
> > pages of size.
> > fillmem50-no-ccache.gif (graph02) attached file represents the memory
> > when executed fillmem with 50MB as well, but without ccache.
> > The x axis represents the time in seconds and the y axis the memory in
> > kilobytes. Make a comparison between the two graphs, we can see that
> > the ccache adds a overhead because the test spends more time to
> > allocate and free the same memory size. And we have also the number of
> > AnonPages increased. Maybe due the metadata needed for the ccache
> > control.
> > One more thing is, 1000 pages as ccache size are not enough to improve
> > the memory allocation. I didn't use a bigger ccache size because it's
> > not stable yet and the system just freezes if the ccache is bigger (>
> > 10MB for example). Discussing with Nitin, he said me that it's
> > something related to the LRU active list handling. He is investigating
> > this problem.
> >
> > Time Performance
> > --------------------------------------------------------
> > This test intends to evaluate the ccache overhead when executing the
> > memory test and an application. I selected the Firefox startup to
> > measure. Just called firefox at the command line with 'time' to do the
> > measurements. The same way was used to measure the time when executing
> > the fillmem test.
> >
> > fillmem-test-time.gif attached file represents the time measurement
> > when executing the fillmem test discussed above. As you can see, the
> > test is much more faster (almost 3 times) without ccache. I believe it
> > is expected once we naturally have an overhead to use the ccache
> > system: all those chunk's operations, vswap control, etc...
> >
> > firefox-startup[01-02].gif attached files represent the time spent to
> > load firefox. On this test, I executed firefox two times without
> > reboot the machine. I was expecting a gain on the speed when using
> > ccache, once we should have more 'firefox anonpages' in the memory
> > when using ccache. But as we can see, we don't have a big difference
> > when using and not using the ccache. But the startup was faster when
> > ccache was used.
> >
> > Conclusion
> > ------------------------------------------------------
> > I believe that it's early to take some conclusion of the ccache
> > benefits. More use cases must be developed and tested to check the
> > impact and improvements of it. We just have a pre-alpha version and we
> > have to focus on fix the bugs to have a 'real workable' ccache
> > version.
> >
> > References
> > -----------------------------------------------------
> > [1] Memtest Suite. <http://carpanta.dc.fi.udc.es/~quintela/memtest/>
> >
> >
> > Best regards,
> >
> > Anderson Briglia
> > Open Source Mobile Research Center - Embedded Linux Lab
> > Instituto Nokia de Tecnologia - INdT - Manaus/Brazil
> >
> > ------------------------------------------------------------------------
> >
> >
> > ------------------------------------------------------------------------
> >
> >
> > ------------------------------------------------------------------------
> >
> >
> > ------------------------------------------------------------------------
> >
> >
> > ------------------------------------------------------------------------
> >
>
>

Re: [lc-devel] Some testings using ccache pre-alpha 003 for i386

[Nitin G. <nit...@gm...>]

Hi,

Please see new page posted on project home page: 
http://linuxcompressed.sourceforge.net/braindumps
I have detailed here possible explanation for these negative results.

I hope to have some solutions implemented soon :)

Cheers,
Nitin


Anderson Briglia wrote:
> Hi all,
>
> I did some tests using the latest ccache code posted by Nitin Gupta. I
> divided the tests in two types: Memory behavior and time performance.
> All tests had this scenario:
>
> - linus kernel 2.6.18-rc4 with ccache pre-alpha 003 applied
> - qemu with ubuntu-dapper image
> - 128MB of RAM
> - No Swap devices
> - After every test, the machine was rebooted
>
> Memory Behavior
> -----------------------------------------------------------
> This test intends to evaluate what happens on the system when it has a
> high memory load. What is the ccache impact? Is it stable even the
> free memory is critical low?
> To do this test I used memtest 0.0.4 [1], that is a suite of tests
> developed to evaluate the stability and consistency of the Linux
> memory management system. It is composed of some testing programs but
> I used just one test, called fillmem. Fillmem tests the memory
> allocation system. It is useful to check the virtual memory system
> face allocation memory, pagination and swap usage. As its parameter,
> fillmem receives the size of the memory that will be allocated.
>
> fillmem50-ccache1000.gif (graph01) attached file represents the memory
> when executed fillmem with 50MB of parameter and ccache with 1000
> pages of size.
> fillmem50-no-ccache.gif (graph02) attached file represents the memory
> when executed fillmem with 50MB as well, but without ccache.
> The x axis represents the time in seconds and the y axis the memory in
> kilobytes. Make a comparison between the two graphs, we can see that
> the ccache adds a overhead because the test spends more time to
> allocate and free the same memory size. And we have also the number of
> AnonPages increased. Maybe due the metadata needed for the ccache
> control.
> One more thing is, 1000 pages as ccache size are not enough to improve
> the memory allocation. I didn't use a bigger ccache size because it's
> not stable yet and the system just freezes if the ccache is bigger (>
> 10MB for example). Discussing with Nitin, he said me that it's
> something related to the LRU active list handling. He is investigating
> this problem.
>
> Time Performance
> --------------------------------------------------------
> This test intends to evaluate the ccache overhead when executing the
> memory test and an application. I selected the Firefox startup to
> measure. Just called firefox at the command line with 'time' to do the
> measurements. The same way was used to measure the time when executing
> the fillmem test.
>
> fillmem-test-time.gif attached file represents the time measurement
> when executing the fillmem test discussed above. As you can see, the
> test is much more faster (almost 3 times) without ccache. I believe it
> is expected once we naturally have an overhead to use the ccache
> system: all those chunk's operations, vswap control, etc...
>
> firefox-startup[01-02].gif attached files represent the time spent to
> load firefox. On this test, I executed firefox two times without
> reboot the machine. I was expecting a gain on the speed when using
> ccache, once we should have more 'firefox anonpages' in the memory
> when using ccache. But as we can see, we don't have a big difference
> when using and not using the ccache. But the startup was faster when
> ccache was used.
>
> Conclusion
> ------------------------------------------------------
> I believe that it's early to take some conclusion of the ccache
> benefits. More use cases must be developed and tested to check the
> impact and improvements of it. We just have a pre-alpha version and we
> have to focus on fix the bugs to have a 'real workable' ccache
> version.
>
> References
> -----------------------------------------------------
> [1] Memtest Suite. <http://carpanta.dc.fi.udc.es/~quintela/memtest/>
>
>
> Best regards,
>
> Anderson Briglia
> Open Source Mobile Research Center - Embedded Linux Lab
> Instituto Nokia de Tecnologia - INdT - Manaus/Brazil
>
> ------------------------------------------------------------------------
>
>
> ------------------------------------------------------------------------
>
>
> ------------------------------------------------------------------------
>
>
> ------------------------------------------------------------------------
>
>
> ------------------------------------------------------------------------
>

[lc-devel] Announce: Compressed cache alpha-004 release

[Nitin G. <nit...@gm...>]

------------
Project: Compressed Caching for Linux
Git (web): http://dev.laptop.org/git.do?p=projects/linux-mm-cc
Git (git): git://dev.laptop.org/projects/linux-mm-cc
Home Page: http://linuxcompressed.sourceforge.net
------------

Hi All,

This patch now fixes bug of decompressed pages not getting
added to (active) LRU. This now allows compressed cache size to
be set to some practical values (I tested it with size = 10MB).
(Patch is for 2.6.18-rc4-git1)

* Now, following issues remain:

1. Pages that are looked up just to be freed are also
decompressed. They should instead simply be freed from ccache
without the need of decompression.

2. Pages that expand on compression stay associated with vswap
hence come for compression again and again. Maybe we should let
such pages go to swap disk (if exists).



* Some initial ideas for solution to above:

Problem 1: Modify free_swap_and_cache() to not to call
find_get_page(page) if page is in vswap. Instead call another
custom function that simply frees compressed page itself.

Problem 2: I think this can be solved by having another page
flag (PG_uncompressible) which should be cleared when its freed.
But adding yet another page flag doesn't look good (ccache
already uses 2). So, trying to find some alternates.
	To let expanding pages go to swap disks, we need to
re-modify PTEs to now point to a swp_entry_t corresponding to a
real swap -- but this is a slow process! Solution?


Now that the LRU problem is fixed, I will now look into
benchmarks sent by Anderson for further refinement.

Cheers,
Nitin

Re: [lc-devel] Some testings using ccache pre-alpha 003 for i386

[Nitin G. <nit...@gm...>]

Hi all,

I am currently planning home page update. This will take 1-2 days.
After this, I will carefully look at these tests and get a roadmap ready for
future development :)

One immediate thing to consider is improper handling of "real" low memory
conditions. It is surely more involving than: if (!ret) goto out; kind of
'error handling' as is done currently.

These tests will surely reveal many more issues.

Thanks Anderson for these tests! :-)

Cheers,
Nitin


Anderson Briglia wrote:
> Hi all,
>
> I did some tests using the latest ccache code posted by Nitin Gupta. I
> divided the tests in two types: Memory behavior and time performance.
> All tests had this scenario:
>
> - linus kernel 2.6.18-rc4 with ccache pre-alpha 003 applied
> - qemu with ubuntu-dapper image
> - 128MB of RAM
> - No Swap devices
> - After every test, the machine was rebooted
>
> ...<snip>...
>
>
> Conclusion
> ------------------------------------------------------
> I believe that it's early to take some conclusion of the ccache
> benefits. More use cases must be developed and tested to check the
> impact and improvements of it. We just have a pre-alpha version and we
> have to focus on fix the bugs to have a 'real workable' ccache
> version.
>
> References
> -----------------------------------------------------
> [1] Memtest Suite. <http://carpanta.dc.fi.udc.es/~quintela/memtest/>
>
>
> Best regards,
>
> Anderson Briglia
> Open Source Mobile Research Center - Embedded Linux Lab
> Instituto Nokia de Tecnologia - INdT - Manaus/Brazil
>
> ------------------------------------------------------------------------

[lc-devel] Some testings using ccache pre-alpha 003 for i386

[Anderson B. <bri...@gm...>]

Hi all,

I did some tests using the latest ccache code posted by Nitin Gupta. I
divided the tests in two types: Memory behavior and time performance.
All tests had this scenario:

- linus kernel 2.6.18-rc4 with ccache pre-alpha 003 applied
- qemu with ubuntu-dapper image
- 128MB of RAM
- No Swap devices
- After every test, the machine was rebooted

Memory Behavior
-----------------------------------------------------------
This test intends to evaluate what happens on the system when it has a
high memory load. What is the ccache impact? Is it stable even the
free memory is critical low?
To do this test I used memtest 0.0.4 [1], that is a suite of tests
developed to evaluate the stability and consistency of the Linux
memory management system. It is composed of some testing programs but
I used just one test, called fillmem. Fillmem tests the memory
allocation system. It is useful to check the virtual memory system
face allocation memory, pagination and swap usage. As its parameter,
fillmem receives the size of the memory that will be allocated.

fillmem50-ccache1000.gif (graph01) attached file represents the memory
when executed fillmem with 50MB of parameter and ccache with 1000
pages of size.
fillmem50-no-ccache.gif (graph02) attached file represents the memory
when executed fillmem with 50MB as well, but without ccache.
The x axis represents the time in seconds and the y axis the memory in
kilobytes. Make a comparison between the two graphs, we can see that
the ccache adds a overhead because the test spends more time to
allocate and free the same memory size. And we have also the number of
AnonPages increased. Maybe due the metadata needed for the ccache
control.
One more thing is, 1000 pages as ccache size are not enough to improve
the memory allocation. I didn't use a bigger ccache size because it's
not stable yet and the system just freezes if the ccache is bigger (>
10MB for example). Discussing with Nitin, he said me that it's
something related to the LRU active list handling. He is investigating
this problem.

Time Performance
--------------------------------------------------------
This test intends to evaluate the ccache overhead when executing the
memory test and an application. I selected the Firefox startup to
measure. Just called firefox at the command line with 'time' to do the
measurements. The same way was used to measure the time when executing
the fillmem test.

fillmem-test-time.gif attached file represents the time measurement
when executing the fillmem test discussed above. As you can see, the
test is much more faster (almost 3 times) without ccache. I believe it
is expected once we naturally have an overhead to use the ccache
system: all those chunk's operations, vswap control, etc...

firefox-startup[01-02].gif attached files represent the time spent to
load firefox. On this test, I executed firefox two times without
reboot the machine. I was expecting a gain on the speed when using
ccache, once we should have more 'firefox anonpages' in the memory
when using ccache. But as we can see, we don't have a big difference
when using and not using the ccache. But the startup was faster when
ccache was used.

Conclusion
------------------------------------------------------
I believe that it's early to take some conclusion of the ccache
benefits. More use cases must be developed and tested to check the
impact and improvements of it. We just have a pre-alpha version and we
have to focus on fix the bugs to have a 'real workable' ccache
version.

References
-----------------------------------------------------
[1] Memtest Suite. <http://carpanta.dc.fi.udc.es/~quintela/memtest/>


Best regards,

Anderson Briglia
Open Source Mobile Research Center - Embedded Linux Lab
Instituto Nokia de Tecnologia - INdT - Manaus/Brazil

[lc-devel] Weekly work summary [11/12]

[Nitin G. <nit...@gm...>]

------------
Project: Compressed Caching for Linux
Git (web): http://dev.laptop.org/git.do?p=projects/linux-mm-cc
Git (git): git://dev.laptop.org/projects/linux-mm-cc
------------

Hi!

This is weekly work summary [11/12] and happy to say its
'ccache-anon-alpha-003' release :)

It is 'nearly' complete compressed caching feature for anonymous pages.

Changes from 'alpha-002'
------------------------
-- LZO de/compression is now working! So, pages are now compressed cyclically
with algos WKdm, WK4x4 and LZO and stored in the compression structure.

-- Proper error code propagation in compress()->wrapper()->real_compress(). This
revealed some unusual error conditions.

-- Some code cleanups, random bug fixes.

Known Problems
--------------

-- Pages decompressed on lookup are not added to (active) LRU. Doing this is
strangely causing system freeze and still no idea why this is happening.

-- Pages that expand on compression are pinned in memory and come again and
again for compression (since they stay assigned to vswap). Should write such
pages to swap disk (if exists).

-- Pages are decompressed even when they are looked-up just to be freed. In
these cases, compressed page chunks should simply be freed.

TODO
----

-- Fix above and code cleanups.

-- Test and Benchmark on OLPC board (and desktop) and post prelim results.

Re: [lc-devel] [OLPC-devel] Re: Announce: Compressed cache 'alpha-002' release

[Jim G. <jg...@la...>]

On Wed, 2006-08-09 at 12:06 +0530, Nitin Gupta wrote:
> Christopher Blizzard wrote:
> > Rik van Riel wrote:
> >> Marcelo isn't currently online due to an accident, but I talked to
> >> him on the phone today.  He said he definately wants to use compressed
> >> swap on OLPC, so I think it would be good if you could work on
> >> stabilizing the current code for use on the OLPC board.
> >>
> >> Open source being what it is, I'm sure somebody will add the page
> >> cache stuff and the adaptive ccache bits.  Especially if they have
> >> a stable base to work from :)
> >>
> >
> > We've talked on and off about allowing some limited swapping to the 
> > flash under emergency circumstances.  But no one has come along with a 
> > concrete way to do that yet.
> >
> I think its already done. When compressed cache reaches its size limit 
> (set by user), pages as sent to swap disks.
> 
> But, if you meant handling wear leveling issues (and maybe others) for 
> swapping over flash, then that is not yet done :) The usual swapping 
> code is still used which aims to minimize disk seeks.
> 

That's ok, I think.  IIRC, IBM released a flash layer recently that will
allow for wear leveling even with multiple partitions.  Dave Woodhouse
hopes to get it set up for us to use.  Even if not, we could swap to
file, where wear leveling would take place.
                              Regards,
                                   - Jim

-- 
Jim Gettys
One Laptop Per Child