public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Bill Davidsen <davidsen@tmr.com>
To: lgb@lgb.hu
Cc: linux-kernel@vger.kernel.org
Subject: Re: Kernel cached memory
Date: Mon, 25 Jul 2005 12:47:50 -0400	[thread overview]
Message-ID: <42E517B6.1010704@tmr.com> (raw)
In-Reply-To: <20050722132523.GJ20995@vega.lgb.hu>

Gábor Lénárt wrote:
> On Fri, Jul 22, 2005 at 05:46:58PM +0800, Ashley wrote:
> 
>>   I've a server with 2 Operton 64bit CPU and 12G memory, and this server 
>>is used to run  applications which will comsume huge memory,
>>the problem is: when this aplications exits,  the free memory of the server 
>>is still very low(accroding to the output of "top"), and
>>from the output of command "free", I can see that many GB memory was cached 
>>by kernel. Does anyone know how to free the kernel cached
>>memory? thanks in advance.
> 
> 
> It's a very - very - very old and bad logic (at least nowdays) from the
> stone age to free up memory.

It's very Microsoft to claim that the OS always knows best, and not let 
the user tune the system the way they want it tuned. And if that means 
to leave a bunch of free memory for absolute fastest availability, the 
admin should have that option.

>                              Memory is for using ... If you have memory why
> don't you want to use? For an actively used system, memory should be used as
> much as possible to maximize the performance. The only problem when kernel
> does not want to "give back" used memory for eg caching for an application
> though but it's another problem ...

No, that's the problem he's trying to address.
> 
> Anyway, want to have 'free memory' is a thing like having dozens of cars
> in your garage which don't want to be used ...
> 
Which wait to be used when needed, rather than after someone cleans a 
bunch of old junk out of them and scurries around the garage looking for 
the right car to let you use.

Just because default operation works well for you, kindly don't try to 
convice us that there are no cases when the default operation is NOT 
optimal. And IMHO Linux is *way* too willing to evicy clean pages of my 
programs to use as disk buffer, so that when system memory is full I pay 
the overhead of TWO disk i/o's, one to finally write the data to the 
disk and one to read my program back in. If free software is about 
choice, I wish there was more in the area of how memory is used.

-- 
    -bill davidsen (davidsen@tmr.com)
"The secret to procrastination is to put things off until the
  last possible moment - but no longer"  -me

  parent reply	other threads:[~2005-07-25 16:43 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-07-22  9:46 Kernel cached memory Ashley
2005-07-22 11:31 ` Diego Calleja
2005-07-22 12:57 ` Erik Mouw
2005-07-22 21:43   ` John Pearson
2005-07-23 12:31     ` Denis Vlasenko
2005-07-22 13:25 ` Gábor Lénárt
2005-07-22 17:58   ` Lee Revell
2005-07-23 10:50     ` Oliver Neukum
2005-07-25 16:47   ` Bill Davidsen [this message]
2005-07-25 17:03     ` Diego Calleja
2005-07-25 17:07     ` Paolo Ornati
2005-07-25 18:02       ` Bill Davidsen
2005-08-01 10:38     ` Gábor Lénárt
2005-08-01 21:08       ` Bill Davidsen
  -- strict thread matches above, loose matches on Subject: below --
2005-07-26  0:35 Chuck Ebbert
     [not found] <4t5s8-68A-33@gated-at.bofh.it>
     [not found] ` <4tdIU-479-9@gated-at.bofh.it>
2005-07-26  5:03   ` Robert Hancock
2005-07-26 15:00     ` Bill Davidsen

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=42E517B6.1010704@tmr.com \
    --to=davidsen@tmr.com \
    --cc=lgb@lgb.hu \
    --cc=linux-kernel@vger.kernel.org \
    /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