From: Dirk Wetter <dirkw@rentec.com>
To: Rik van Riel <riel@conectiva.com.br>
Cc: Wayne Whitney <whitney@math.berkeley.edu>, linux-kernel@vger.kernel.org
Subject: Re: dead mem pages
Date: Wed, 11 Jul 2001 01:04:07 -0500 [thread overview]
Message-ID: <3B4BEC57.7000509@rentec.com> (raw)
In-Reply-To: <Pine.LNX.4.33L.0107102013560.2836-100000@imladris.rielhome.conectiva>
Rik,
thx for your answer. :)
Rik van Riel wrote:
>On Tue, 10 Jul 2001, Dirk Wetter wrote:
>
>>>It would be good to know what these 2.8GB of cached pages are.
>>>
>>believe me, i would like to know too where all the $$$ memory
>>went to. ;-)
>>
>
>Most likely swap cache, that means it is the memory from your
>simulations, just removed from the page tables and put in the
>swap cache.
>
but why was the machine actually swapping then? sar definetely showed swap
and disk activity as the applications started.
>>>Again on a general note, the 2.4 kernel's VM is new and hence not fully
>>>mature. So the short and unhelpful answer to your query is probably that
>>>the current VM system is not well tuned for your workload (4.3GB of memory
>>>hungry simulations on a 4GB machine).
>>>
>>concerning the maturity that's also the answer i got from the kernel
>>guru's at last USENIX in boston. but ihmo it *should* become soon
>>better for the future if Linux intends to become bigger in the server
>>business. (my $0.02)
>>
>
>It'll get better as soon as we have the time, for 2.4.7
>the VM statistics have already improved a bit so people
>are no longer fooled by large "cached" figures ;)
>
Rik (and Wayne): it's *not only* the statistics. they were swapping like
crazy.
the only thing the machines were responding immediately to were icmp
packets.
no tcp/udp. keystrokes on the console were echoed 2 minutes after i
typed the command
in. with some patience i managed to execute "top" i caught pictures were
kswapd
was in the first line having 99% or so of one CPU and the load was between
20 and 30.
>
>Actual improvements to the code, if needed at all, will
>come with time ... more than $0.02 will get you ;)
>
not that i don't appreciate very much your work, but i had to learn that
improvements are
needed: we could swap our 4GB machines to death just by submitting jobs
in the size
of the ~physical memory to them. but i don't have any doubts that you
guys will manage
to do neccessary changes:-)
i do the profile tests Marcelo suggested (thx) and come back with some
numbers.
tschuess :-)
~dirkw
prev parent reply other threads:[~2001-07-11 5:04 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <Pine.LNX.4.33.0107100941270.5644-100000@mf1.private>
2001-07-10 22:38 ` dead mem pages Dirk Wetter
2001-07-10 23:27 ` Rik van Riel
2001-07-11 6:04 ` Dirk Wetter [this message]
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=3B4BEC57.7000509@rentec.com \
--to=dirkw@rentec.com \
--cc=linux-kernel@vger.kernel.org \
--cc=riel@conectiva.com.br \
--cc=whitney@math.berkeley.edu \
/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