From: Benjamin King <benjaminking@web.de>
To: linux-perf-users@vger.kernel.org
Subject: Re: How to sample memory usage cheaply?
Date: Mon, 3 Apr 2017 21:09:50 +0200 [thread overview]
Message-ID: <20170403190950.GA29118@localhost> (raw)
In-Reply-To: <20170330200404.GA1915@localhost>
On Thu, Mar 30, 2017 at 10:04:04PM +0200, Benjamin King wrote:
Hi,
I learned a bit more about observing memory with perf. If this is not the
right place to discuss this any more, just tell me to shut up :-)
wrapping this up a bit:
>I'd like to get a big picture of where a memory hogging process uses physical
>memory. I'm interested in call graphs, [...] I'd love to
>analyze page faults
I have learned that first use of a physical page is called "page allocation",
which can be traced via the event kmem:mm_page_alloc. This is the pyhsical
analogue of and different from "page faults" that happen in virtual memory.
Maping a file with MAP_POPULATE after dropping filesystem caches (sysctl -w
vm.drop_caches=3) will show the right number in kmem:mm_page_alloc, namely
the size/4K. 4K is the page size on my system.
If I do the same again without dropping caches in between, mm_page_alloc does
not show the same number, but rather the number of pages it takes to hold the
page table entries. This is nice and fairly complete, but I still hope to
find a way to observe when a page from the filesystem cache is referenced for
the first time from my process. This would allow me to do without the cache
dropping.
Page faults from virtual memory are more opaque to me. They only seem to be
counted when the system did not prepare the process via prefetching. For
example, MAP_POPULATE'd mappings will not count towards page faults, neither
minor nor major ones.
To control some of the prefetching, there is a debugfs knob called
/sys/kernel/debug/fault_around_bytes, but reducing this to the minimum on my
machine does not produce a page fault number that I could easily explain, at
least not in the MAP_POPULATE case. It might work better when actually
reading data from the mapped file.
Anticipating page faults and preventing them proactively is a nice service
from the OS, but I would be delighted if there was a way to trace this as
well, similar to how mm_page_alloc will count each and every pyhsical
allocation. This would make page faults more useful as a poor man's memory
tracker.
Cheers,
Benjamin
prev parent reply other threads:[~2017-04-03 19:09 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-03-30 20:04 How to sample memory usage cheaply? Benjamin King
2017-03-31 12:06 ` Milian Wolff
2017-04-01 7:41 ` Benjamin King
2017-04-01 13:54 ` Vince Weaver
2017-04-01 16:27 ` Benjamin King
2017-04-03 19:09 ` Benjamin King [this message]
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=20170403190950.GA29118@localhost \
--to=benjaminking@web.de \
--cc=linux-perf-users@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;
as well as URLs for NNTP newsgroup(s).