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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.