Re: cache limit

[William Lee Irwin III <wli@holomorphy.com>]

On Wed, 27 Aug 2003 02:45:12 -0700, William Lee Irwin III wrote:
>> How do you know it would be effective? Have you written a patch to
>> limit it in some way and tried running it?

On Wed, Aug 27, 2003 at 08:14:12PM +0900, Takao Indoh wrote:
> It's just my guess. You mean that "index cache" is on the pagecache?
> "index cache" is allocated in the user space by malloc,
> so I think it is not on the pagecache.

That will be in the pagecache.


On Wed, 27 Aug 2003 02:45:12 -0700, William Lee Irwin III wrote:
>> How do you know most of it is unmapped?

On Wed, Aug 27, 2003 at 08:14:12PM +0900, Takao Indoh wrote:
> I checked /proc/meminfo.
> For example, this is my /proc/meminfo(kernel 2.5.73)
[...]
> Buffers:         18520 kB
> Cached:         732360 kB
> SwapCached:          0 kB
> Active:         623068 kB
> Inactive:       179552 kB
[...]
> Dirty:           33204 kB
> Writeback:           0 kB
> Mapped:          73360 kB
> Slab:            32468 kB
> Committed_AS:   167396 kB
[...]
> According to this information, I thought that
> all pagecache was 732360 kB and all mapped page was 73360 kB, so
> almost of pagecache was not mapped...
> Do I misread meminfo?

No. Most of your pagecache is unmapped pagecache. This would correspond
to memory that caches files which are not being mmapped by any process.
This could result from either the page replacement policy favoring
filesystem cache too heavily or from lots of io causing the filesystem
cache to be too bloated and so defeating the swapper's heuristics (you
can do this by generating large amounts of read() traffic).

Limiting unmapped pagecache would resolve your issue. Whether it's the
right thing to do is still open to question without some knowledge of
application behavior (for instance, teaching userspace to do fadvise()
may be right thing to do as opposed to the /proc/ tunable).

Can you gather traces of system calls being made by the applications?


-- wli