All of lore.kernel.org
 help / color / mirror / Atom feed
From: Nix <nix@esperi.org.uk>
To: Nick Warne <nick@linicks.net>
Cc: linux-kernel@vger.kernel.org
Subject: Re: 2.4.28 -> ch..ch...changes....
Date: Fri, 26 Nov 2004 11:53:58 +0000	[thread overview]
Message-ID: <877jo8u8q1.fsf@amaterasu.srvr.nix> (raw)
In-Reply-To: <200411241957.14527.nick@linicks.net> (Nick Warne's message of "24 Nov 2004 23:27:43 -0000")

On 24 Nov 2004, Nick Warne mused:
> Normally memory slowly fills up, perhaps using swap for a bit under these 
> circumstances - but looking afterwards:

This is a feature, not a bug. Free memory is wasted memory (although
some has to be kept free for drivers that need GFP_ATOMIC allocations:
i.e. `memory *now* dammit *now*'.

> root@linuxamd:~# free
>              total       used       free     shared    buffers     cached
> Mem:       1292348     520012     772336          0      38596     327304
> -/+ buffers/cache:     154112    1138236
> Swap:      1959888          0    1959888

The only thing I can think of that causes this is something very
memory-hungry that's just been killed, releasing a pile of pages back to
the system.

> But whatever, I am impressed indeed - somethings changed for the good!!!

I see no signs of such a change on my 2.4.28 boxes:

(UltraSPARC II)
             total       used       free     shared    buffers     cached
Mem:        509360     498432      10928          0     133568      52656
-/+ buffers/cache:     312208     197152
Swap:      1557264     143992    1413272

(Athlon IV)
             total       used       free     shared    buffers     cached
Mem:        775072     762744      12328          0      88304     322740
-/+ buffers/cache:     351700     423372
Swap:      1048560      81020     967540

(i586)
             total       used       free     shared    buffers     cached
Mem:        126992     123640       3352          0      11792      42012
-/+ buffers/cache:      69836      57156
Swap:      1245168     155560    1089608

The only suspiciously high free figure is on a 2.4.28 UML instance
(2.4.28 + forward-ported 2.4.27-1 patches) on one of those machines:

             total       used       free     shared    buffers     cached
Mem:         94000      66512      27488          0       2940      31260
-/+ buffers/cache:      32312      61688
Swap:            0          0          0

and that is trivially obviously caused by the instance's lack of swap :)

-- 
`The sword we forged has turned upon us
 Only now, at the end of all things do we see
 The lamp-bearer dies; only the lamp burns on.'

  reply	other threads:[~2004-11-27  5:47 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-11-23 21:36 2.4.28 -> ch..ch...changes Nick Warne
2004-11-24  7:08 ` Marcelo Tosatti
2004-11-24 17:48   ` Hugh Dickins
2004-11-24 19:57     ` Nick Warne
2004-11-26 11:53       ` Nix [this message]
2004-11-27 15:42         ` Nick Warne

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=877jo8u8q1.fsf@amaterasu.srvr.nix \
    --to=nix@esperi.org.uk \
    --cc=linux-kernel@vger.kernel.org \
    --cc=nick@linicks.net \
    /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.