public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Con Kolivas <kernel@kolivas.org>
To: Kimmo Sundqvist <rabbit80@mbnet.fi>, linux-kernel@vger.kernel.org
Cc: rcastro@users.sourceforge.net
Subject: Re: [2.4.20-ck7] good compressed caching experience
Date: Tue, 27 May 2003 07:11:34 +1000	[thread overview]
Message-ID: <200305270711.34608.kernel@kolivas.org> (raw)
In-Reply-To: <200305262150.04552.rabbit80@mbnet.fi>

On Tue, 27 May 2003 04:50, Kimmo Sundqvist wrote:
> Hello

Hi Kimmo

> 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.
>
> This was with Con's ck7pre versions released on 24th and 25th of May.
>
> Now running 2.4.20-ck7pre with compressed cache in a dual CPU machine with
> SMP disabled (compressed caching and SMP support are still mutually
> 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.
>
> This machine has a Seagate Barracuda V 80GB, which does sequential reads at
> 40MB/s.  I could drive this into trashing, then type "sar -B 1 1000" and
> see how the swap is doing.  Now, compressed caching brings me benefit if,
> and only if, it can compress and decompress pages faster than that in this
> CPU, which it sure does, since this is a Pentium III 933MHz, but I'm not
> sure about the little brother's Pentium 133MHz.  It has a 4GB Seagate that
> does 6MB/s sequentially.  Did I figure it out correctly?  Of course
> swapping to a partition gets slower as the swap usage increases.  Longer
> seeks and the like.

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. 
>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. 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.

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.

I've cc'ed the actual developer of cc as he has indicated that he is actively 
working on compressed caching again.

> 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.

Cheers,
Con

  reply	other threads:[~2003-05-26 20:56 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 [this message]
2003-05-27  1:41   ` Rodrigo Souza de Castro
2003-05-27  3:37     ` Con Kolivas
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=200305270711.34608.kernel@kolivas.org \
    --to=kernel@kolivas.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rabbit80@mbnet.fi \
    --cc=rcastro@users.sourceforge.net \
    /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