From: Howard Chu <hyc@symas.com>
To: Johannes Weiner <hannes@cmpxchg.org>, Jan Kara <jack@suse.cz>
Cc: linux-kernel <linux-kernel@vger.kernel.org>, linux-mm@kvack.org
Subject: Re: mmap vs fs cache
Date: Thu, 07 Mar 2013 23:46:39 -0800 [thread overview]
Message-ID: <5139975F.9070509@symas.com> (raw)
In-Reply-To: <20130308020854.GC23767@cmpxchg.org>
Johannes Weiner wrote:
> On Thu, Mar 07, 2013 at 04:43:12PM +0100, Jan Kara wrote:
>>> 2 questions:
>>> why is there data in the FS cache that isn't owned by (the mmap
>>> of) the process that caused it to be paged in in the first place?
>
> The filesystem cache is shared among processes because the filesystem
> is also shared among processes. If another task were to access the
> same file, we still should only have one copy of that data in memory.
That's irrelevant to the question. As I already explained, the first 16GB that
was paged in didn't behave this way. Perhaps "owned" was the wrong word, since
this is a MAP_SHARED mapping. But the point is that the memory is not being
accounted in slapd's process size, when it was before, up to 16GB.
> It sounds to me like slapd is itself caching all the data it reads.
You're misreading the information then. slapd is doing no caching of its own,
its RSS and SHR memory size are both the same. All it is using is the mmap,
nothing else. The RSS == SHR == FS cache, up to 16GB. RSS is always == SHR,
but above 16GB they grow more slowly than the FS cache.
> If that is true, shouldn't it really be using direct IO to prevent
> this double buffering of filesystem data in memory?
There is no double buffering.
>>> is there a tunable knob to discourage the page cache from stealing
>>> from the process?
>
> Try reducing /proc/sys/vm/swappiness, which ranges from 0-100 and
> defaults to 60.
I've already tried setting it to 0 with no effect.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2013-03-08 7:46 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <5136320E.8030109@symas.com>
2013-03-07 15:43 ` Jan Kara
2013-03-08 2:08 ` Johannes Weiner
2013-03-08 7:46 ` Howard Chu [this message]
2013-03-08 8:42 ` Kirill A. Shutemov
2013-03-08 9:40 ` Howard Chu
2013-03-08 14:47 ` Chris Friesen
2013-03-08 15:00 ` Howard Chu
2013-03-08 15:25 ` Chris Friesen
2013-03-08 16:16 ` Johannes Weiner
2013-03-08 20:04 ` Howard Chu
2013-03-11 12:04 ` Jan Kara
2013-03-11 12:40 ` Howard Chu
2013-03-09 3:28 ` Ric Mason
2013-03-09 1:22 ` Phillip Susi
2013-03-11 11:52 ` Jan Kara
2013-03-11 15:03 ` Phillip Susi
2013-03-09 2:34 ` Ric Mason
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=5139975F.9070509@symas.com \
--to=hyc@symas.com \
--cc=hannes@cmpxchg.org \
--cc=jack@suse.cz \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.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