mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Takao Indoh <indou.takao@soft.fujitsu.com>
To: William Lee Irwin III <wli@holomorphy.com>,
	Mike Fedyk <mfedyk@matchmail.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: cache limit
Date: Wed, 27 Aug 2003 18:36:10 +0900	[thread overview]
Message-ID: <19C36C7EA5D3E5indou.takao@soft.fujitsu.com> (raw)
In-Reply-To: <20030826094634.GP4306@holomorphy.com>

Thanks for advice.

On Mon, 25 Aug 2003 15:58:47 -0700, Mike Fedyk wrote:

>I doubt that there will be that option in the 2.4 stable series.  I think
>you are trying to fix the problem without understanding the entire picture.
>If there is too much pagechache, then the kernel developers need to know
>about your workload so that they can fix it.  But you have to try -aa first
>to see if it's already fixed.
>
>> This is moderately misguided; essentially the only way userspace can
>> utilize RAM at all is via the pagecache. It's not useful to limit this;
>> you probably need inode-highmem or some such nonsense.
>
>Exactly.  Every program you have opened, and all of its libraries will show
>up as pagecache memory also, so seeing a large pagecache in and of itself
>may not be a problem.
>
>Let's get past the tuning paramenter you want in /proc, and tell us more
>about what you are doing that is causing this problem to be shown.

This problem happened a few month ago and the detailed data does not
remain. Therefore it is difficult to know what is essential cause for
this problem, but, I guessed that pagecache used as I/O cache grew
gradually during system running, and finally it oppressed memory.

Besides this problem, there are many cases where increase of pagecache
causes trouble, I think.
For example, DBMS.
DBMS caches index of DB in their process space.
This index cache conflicts with the pagecache used by other applications,
and index cache may be paged out. It cause uneven response of DBMS.
In this case, limiting pagecache is effective.


On Tue, 26 Aug 2003 02:46:34 -0700, William Lee Irwin III wrote:

>One thing I thought of after the post was whether they actually had in
>mind tunable hard limits on _unmapped_ pagecache, which is, in fact,
>useful. OTOH that's largely speculation and we really need them to
>articulate the true nature of their problem.

I also think that is effective. Empirically, in the case where pagecache
causes memory shortage, most of pagecache is unmapped page. Of course
real problem may not be pagecashe, as you or Mike said.

--------------------------------------------------
Takao Indoh
 E-Mail : indou.takao@soft.fujitsu.com


  reply	other threads:[~2003-08-27  9:35 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-08-19  4:39 Anthony R.
2003-08-19  4:57 ` Nuno Silva
2003-08-19  5:33 ` Denis Vlasenko
2003-08-19  6:20   ` Andrew Morton
2003-08-19  9:05     ` J.A. Magallon
2003-08-19  9:16       ` Andrew Morton
2003-08-19  9:28         ` J.A. Magallon
2003-08-19  9:43           ` Andrew Morton
2003-08-19 13:32     ` Erik Andersen
2003-08-19 20:56       ` Andrew Morton
2003-08-19 14:28   ` Anthony R.
2003-08-19 18:26     ` Mike Fedyk
2003-08-19  5:42 ` Nick Piggin
2003-08-21  0:49 ` Takao Indoh
2003-08-21 23:47   ` Mike Fedyk
2003-08-25  2:45     ` Takao Indoh
2003-08-25  4:11       ` William Lee Irwin III
2003-08-25 22:58         ` Mike Fedyk
2003-08-26  9:46           ` William Lee Irwin III
2003-08-27  9:36             ` Takao Indoh [this message]
2003-08-27  9:45               ` William Lee Irwin III
2003-08-27 11:14                 ` Takao Indoh
2003-08-27 11:36                   ` William Lee Irwin III
2003-09-02 10:52                     ` Takao Indoh
2003-09-02 11:30                       ` William Lee Irwin III
2003-09-02 17:21                       ` Mike Fedyk
2003-08-27 16:01                 ` Joseph Malicki
     [not found] <m6Bv.3ys.1@gated-at.bofh.it>
     [not found] ` <mLY8.dO.5@gated-at.bofh.it>
2003-08-21  9:52   ` Ihar 'Philips' Filipau
2003-08-25  7:17     ` Takao Indoh
     [not found] <n7lV.2HA.19@gated-at.bofh.it>
     [not found] ` <ofAJ.4dx.9@gated-at.bofh.it>
     [not found]   ` <ogZM.5KJ.1@gated-at.bofh.it>
     [not found]     ` <oyDw.5FP.33@gated-at.bofh.it>
2003-08-26 10:15       ` Ihar 'Philips' Filipau
2003-08-26 17:46         ` Mike Fedyk
     [not found] <oJ5P.699.21@gated-at.bofh.it>
     [not found] ` <oJ5P.699.23@gated-at.bofh.it>
     [not found]   ` <oJ5P.699.25@gated-at.bofh.it>
     [not found]     ` <oJ5P.699.27@gated-at.bofh.it>
     [not found]       ` <oJ5P.699.19@gated-at.bofh.it>
     [not found]         ` <oQh2.4bQ.13@gated-at.bofh.it>
2003-08-26 19:08           ` Ihar 'Philips' Filipau
2003-08-26 19:23             ` Mike Fedyk
2003-08-27 10:21               ` Ihar 'Philips' Filipau
2003-08-27 11:07                 ` Nick Piggin
     [not found] <000801c36cb1$454d4950$1001a8c0@etofmv650>
2003-08-27 16:02 ` YoshiyaETO
2003-08-27 16:03 Joseph Malicki

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=19C36C7EA5D3E5indou.takao@soft.fujitsu.com \
    --to=indou.takao@soft.fujitsu.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mfedyk@matchmail.com \
    --cc=wli@holomorphy.com \
    /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

all inboxes | Powered by JetHome®