From: Paul <set@pobox.com>
To: Rik van Riel <riel@conectiva.com.br>,
lkml <linux-kernel@vger.kernel.org>
Subject: Re: 2.4.10 much better than previous 2.4.x :-)
Date: Fri, 28 Sep 2001 00:53:03 -0400 [thread overview]
Message-ID: <20010928005302.A226@squish.home.loc> (raw)
In-Reply-To: <1001377785.1430.7.camel@gromit.house> <Pine.LNX.4.33L.0109242234410.19147-100000@imladris.rielhome.conectiva> <20010925203515.A227@squish.home.loc>
In-Reply-To: <20010925203515.A227@squish.home.loc>; from set@pobox.com on Tue, Sep 25, 2001 at 08:35:15PM -0400
Hi.
Got 2.4.9-ac16, and ran the 'test' described in my previous
post in this thread, and some benchmarks. Interactive performance
was fine, but not quite as snappy as 2.4.9-ac15. I think this is
because 2.4.9-ac15 just didnt want to swap, due no doubt to the
mispatch. I guess everything I do 'normally' tends to fit well
within my available memory.
Aiming the gun squarely at my toe again, I modified my
malloc program to write to the mem it allocs, and sleep 50us,
so I can watch it progress. Quite different results this time:
(I have 128M ram and 330M swap)
Mal's RSS climbed to around 60-90M, eating up free mem
until free mem was at 2.8M. Then some of the buffers and cache
drained. (mot much though-- I kept moving around the virtual
desktop and doing stuff, and interactivity was fine, and disk
was extremely quiet during whole test). After Mal drained as much
from cache and buff as it could, it would go to swap periodicly,
until eventually all of swap was used up. Then it started on the
buff and cache again-- it didnt seem to completely deplete them,
but they got down pretty low. Then it finally started getting
some of that 2.8M free memory that had been reserved this whole
time. Swap was completely full, cache and buff were very low, and
free mem went to zip. Then the OOM killer took it. At no point was the
machine thrashing.
I dont know if this really says anything, but it was
comforting to see such a seemingly rational smooth progression
and termination:)
Then I modified Mal to write to every chunk it had malloc'd
each time it malloc'd more. This is punishing:) After a while it
is a fight with Mal and everyone to be in memory. Disk activity
becomes contant, and things keep getting swapped out, however, Im
writing this with some degree of interactive degradation as it
goes on. Load is only 2, and Mal has slowed to a crawl, but the
machine is running as well as can be expected.
Thanks;
Paul
set@pobox.com
next prev parent reply other threads:[~2001-09-28 4:54 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-09-25 0:29 Michael Rothwell
2001-09-25 1:35 ` Rik van Riel
2001-09-26 0:35 ` Paul
2001-09-26 20:08 ` José Luis Domingo López
2001-09-27 8:17 ` Helge Hafting
2001-09-28 4:53 ` Paul [this message]
2001-09-25 15:20 ` Something Broken in 2.4.9-ac15 Kent Borg
2001-09-25 16:51 ` Kent Borg
2001-09-26 0:06 ` 2.4.10 much better than previous 2.4.x :-) Andrea Arcangeli
2001-09-25 16:18 Martin Knoblauch
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=20010928005302.A226@squish.home.loc \
--to=set@pobox.com \
--cc=linux-kernel@vger.kernel.org \
--cc=riel@conectiva.com.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
all inboxes | Powered by JetHome®