public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Con Kolivas <kernel@kolivas.org>
To: Rodrigo Souza de Castro <rcastro@ime.usp.br>
Cc: Kimmo Sundqvist <rabbit80@mbnet.fi>,
	linux-kernel@vger.kernel.org,
	linuxcompressed-devel@lists.sourceforge.net
Subject: Re: [2.4.20-ck7] good compressed caching experience
Date: Tue, 27 May 2003 13:37:20 +1000	[thread overview]
Message-ID: <200305271337.20465.kernel@kolivas.org> (raw)
In-Reply-To: <20030527014124.GE3388@bach>

On Tue, 27 May 2003 11:41, Rodrigo Souza de Castro wrote:
> Hi Con,
>
> On Tue, May 27, 2003 at 07:11:34AM +1000, Con Kolivas wrote:
> > On Tue, 27 May 2003 04:50, Kimmo Sundqvist wrote:
> > > I just decided to tell everyone that I've been able to run 2.4.20-ck7
> > > with compressed caching enabled in my little brother's Pentium 133MHz,
> > > for hours, doing stress testing, compiling kernels and using the
> > > Internet under X.
> > >
> > > I had pre-empt enabled.  Compressed swap worked also.  I used 4kB pages
> > > without compressed swap, and 8kB with it.
>
> [snip]
>
> > > exclusive), 1GB of RAM but "mem=128M" for testing purposes.  Been
> > > stable for 6 hours now, and done even some stress testing.  Try 128
> > > instances of burnBX with 1MB each, like "for ((A=128;A--;A<1)) do
> > > burnBX J & done".  A nice brute force or "if you don't behave I'll push
> > > all my buttons" method
> > >
> > > :)
> > >
> > > Wondering if Pentium 133MHz (64MB RAM) is fast enough to benefit from
> > > compressed caching.  I know there's a limit, depending on the speed of
> > > the CPU and the speed of the swap partition (doing random accesses),
> > > which determines if compressed caching is beneficial or not.
>
> [snip]
>
> > What you describe has been my experience with cc as well. I haven't
> > had any crashes or unusual problems with it since removing the AA vm
> > changes as well - it seemed to be the combination that caused
> > hiccups on extreme testing.
>
> Something to be figured out yet. It is a pity we couldn't work harder
> on these problems.

I think getting the stability necessary on the main tree was far more 
important so I don't regret this.

>
> > >From what I can see, no matter how slow your cpu you will still get
> >
> > benefit from cc as the hard drives on those machines are
> > proportionately slower as well.
>
> I guess that, in the past, the gap was smaller, but still there.
>
> > The one limitation of cc is that it does require _some_ ram to
> > actually store swap pages in, and it seems that you need more than
> > 32Mb ram to start deriving benefit.
>
> I am not sure. It requires some ram, but it is only a few pages to
> avoid failed page allocations when it first needs to allocate pages. I
> have a report of running CC on a laptop with 8M RAM, that showed to be
> a little more responsive. I don't have a scientific results showing
> that is better on system with a lower amount of memory, but this
> feedback seems positive.
>
> > One minor thing, though - my vm hacks make compressed caching work
> > much less than it normally does as they try to avoid swapping quite
> > aggressively. It is when the vm attempts to start swapping that cc
> > looks to see if it should take pages into compressed cache instead.
>
> What exactly are your VM hacks concerning CC? The default behaviour is
> to compress pages only when the VM starts freeing pages, not in a
> compress-ahead fashion, pretty much what I think you said above.

Ok, I didn't look at your code, but that would make sense too because with my 
hacks it will start even lower priority than the default VM freeing less 
pages at a time unless the memory pressure gets high.

>
> > I've cc'ed the actual developer of cc as he has indicated that he is
> > actively working on compressed caching again.
>
> At a slower pace, but finally back to CC development. :-)

Excellent. Good to have you back.
>
> > > Just a warning... both systems have only ReiserFS partitions.
> > > Other FSes might still get hurt.
> >
> > This is definitely the case! If you try out compressed caching with
> > ck7 please do not enable preempt if you are using ext2/3 or vfat.
>
> As told in a previous email, I wouldn't enable preempt in any case
> with this code version.

-ck has always come with a warning saying as much. I hope to integrate more of 
your code when you're happy with it, so this problem can be resolved.

Cheers,
Con

  reply	other threads:[~2003-05-27  3:22 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-05-26 18:50 [2.4.20-ck7] good compressed caching experience Kimmo Sundqvist
2003-05-26 21:11 ` Con Kolivas
2003-05-27  1:41   ` Rodrigo Souza de Castro
2003-05-27  3:37     ` Con Kolivas [this message]
2003-05-27 14:13   ` Kimmo Sundqvist
2003-05-27 14:20     ` Con Kolivas
2003-05-28  2:00     ` Rodrigo Souza de Castro
2003-05-27  1:21 ` Rodrigo Souza de Castro

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200305271337.20465.kernel@kolivas.org \
    --to=kernel@kolivas.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linuxcompressed-devel@lists.sourceforge.net \
    --cc=rabbit80@mbnet.fi \
    --cc=rcastro@ime.usp.br \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox