public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Kimmo Sundqvist <rabbit80@mbnet.fi>
To: linux-kernel@vger.kernel.org
Subject: [2.4.20-ck7] good compressed caching experience
Date: Mon, 26 May 2003 21:50:03 +0300	[thread overview]
Message-ID: <200305262150.04552.rabbit80@mbnet.fi> (raw)

Hello

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.

Just a warning... both systems have only ReiserFS partitions.  Other FSes 
might still get hurt.

-Kimmo Sundqvist

             reply	other threads:[~2003-05-26 18:36 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-05-26 18:50 Kimmo Sundqvist [this message]
2003-05-26 21:11 ` [2.4.20-ck7] good compressed caching experience Con Kolivas
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=200305262150.04552.rabbit80@mbnet.fi \
    --to=rabbit80@mbnet.fi \
    --cc=linux-kernel@vger.kernel.org \
    /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