All of lore.kernel.org
 help / color / mirror / Atom feed
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





      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.