All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jakob Oestergaard <jakob@unthought.net>
To: "Frederick, Fabian" <Fabian.Frederick@prov-liege.be>
Cc: mru@users.sourceforge.net, linux-kernel@vger.kernel.org
Subject: Re: About _real_ free memory
Date: Thu, 16 Oct 2003 13:44:40 +0200	[thread overview]
Message-ID: <20031016114440.GD8711@unthought.net> (raw)
In-Reply-To: <D9B4591FDBACD411B01E00508BB33C1B01F6EE59@mesadm.epl.prov-liege.be>

On Thu, Oct 16, 2003 at 11:04:14AM +0200, Frederick, Fabian wrote:
> If a process tries to allocate and use more than the really free
> amount, some cache will be dropped automatically.  From a performance
> point of view, this could of course be undesirable, but normally
> there's no need to think about it.
> 
> <Why don't we have a command to drop some cache ? or maybe some
> <kernel rules to do it ? we could gain some more scalability doing that kind
> of
> <stuff during low load.

No - you would throw out disk cache with the risk of throwing out
potentially useful data.  The data can be thrown out *immediately*
anyway if someone needs it.

So:  gain: zero
     loss: likely noticable
   ------------------------------
    total: bad idea

>Another problem is end-user point of view :
> 
> <	-What's available on a box before swapping ?
> <	-Do I have to add RAM right now ?

[albatross:joe] $ free
             total       used       free     shared    buffers
cached
Mem:       1033944     902036     131908          0      41120
446456
-/+ buffers/cache:     414460     619484
Swap:      2101000     294552    1806448

I have 619 MB of free memory now, if you do not count in the caches.

The free physical memory is around 132 MB - this number tells me how
much memory the kernel could not find a use for (for either processes or
cache) - e.g. the amount of memory that I paid for but is not doing
anything useful.

You want the physical free memory to be as low as possible - it is the
amount of memory that is being wasted in the system by not doing
anything useful.  If the user cannot understand this, they should learn
not to care either.  Certainly, you should never ruin the workings of
the VM subsystem by freeing useful cache memory, just so a user who has
no understanding of what is actually going on, can get a nice big number
in his 'free' output.

Maybe one could patch the 'free' utility instead?   ;)

-- 
................................................................
:   jakob@unthought.net   : And I see the elder races,         :
:.........................: putrid forms of man                :
:   Jakob Østergaard      : See him rise and claim the earth,  :
:        OZ9ABN           : his downfall is at hand.           :
:.........................:............{Konkhra}...............:

  reply	other threads:[~2003-10-16 11:44 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-10-16  9:04 About _real_ free memory Frederick, Fabian
2003-10-16 11:44 ` Jakob Oestergaard [this message]
  -- strict thread matches above, loose matches on Subject: below --
2003-10-16  7:23 Frederick, Fabian
2003-10-16  7:48 ` Måns Rullgård

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=20031016114440.GD8711@unthought.net \
    --to=jakob@unthought.net \
    --cc=Fabian.Frederick@prov-liege.be \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mru@users.sourceforge.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.