From: Peter Zijlstra <peterz@infradead.org>
To: "Liang, Kan" <kan.liang@linux.intel.com>
Cc: Dave Hansen <dave.hansen@intel.com>,
acme@kernel.org, mingo@redhat.com, linux-kernel@vger.kernel.org,
mark.rutland@arm.com, alexander.shishkin@linux.intel.com,
jolsa@redhat.com, eranian@google.com, ak@linux.intel.com,
kirill.shutemov@linux.intel.com
Subject: Re: [PATCH V6 01/16] perf/core: Add PERF_SAMPLE_DATA_PAGE_SIZE
Date: Tue, 11 Aug 2020 00:47:34 +0200 [thread overview]
Message-ID: <20200810224734.GO3982@worktop.programming.kicks-ass.net> (raw)
In-Reply-To: <298cfc4d-4a9b-7886-1006-09f2bc24d789@linux.intel.com>
On Mon, Aug 10, 2020 at 06:38:35PM -0400, Liang, Kan wrote:
> On 8/10/2020 5:47 PM, Dave Hansen wrote:
> > It's probably best if we very carefully define up front what is getting
> > reported here. For instance, I believe we already have some fun cases
> > with huge tmpfs where a compound page is mapped with 4k PTEs. Kirill
> > also found a few drivers doing this as well. I think there were also
> > some weird cases for ARM hugetlbfs where there were multiple hardware
> > page table entries mapping a single hugetlbfs page. These would be
> > cases where compound_head() size would be greater than the size of the
> > leaf paging structure entry.
> >
> > This is also why we have KerelPageSize and MMUPageSize in /proc/$pid/smaps.
> >
> > So, is this returning the kernel software page size or the MMU size?
> >
>
> This tries to return the kernel software page size. I will add a commit to
> the function. For the above cases, I think they can be detected by
> PageCompound(page). The current code should already cover them. Is my
> understanding correct?
But the rationale for the whole feature was to measure and possibly
drive large page promotion/demotion, which requires the mmu page-size.
next prev parent reply other threads:[~2020-08-10 22:47 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-08-10 21:24 [PATCH V6 00/16] Add the page size in the perf record Kan Liang
2020-08-10 21:24 ` [PATCH V6 01/16] perf/core: Add PERF_SAMPLE_DATA_PAGE_SIZE Kan Liang
2020-08-10 21:35 ` Peter Zijlstra
2020-08-10 21:39 ` Peter Zijlstra
2020-08-10 22:36 ` Liang, Kan
2020-08-10 21:47 ` Dave Hansen
2020-08-10 22:38 ` Liang, Kan
2020-08-10 22:47 ` Peter Zijlstra [this message]
2020-08-12 13:39 ` Liang, Kan
2020-08-12 13:53 ` Dave Hansen
2020-08-10 21:24 ` [PATCH V6 02/16] perf/x86/intel: Support PERF_SAMPLE_DATA_PAGE_SIZE Kan Liang
2020-08-10 21:40 ` Peter Zijlstra
2020-08-10 22:36 ` Liang, Kan
2020-08-10 21:24 ` [PATCH V6 03/16] perf/core: Add support for PERF_SAMPLE_CODE_PAGE_SIZE Kan Liang
2020-08-10 21:41 ` Peter Zijlstra
2020-08-10 22:37 ` Liang, Kan
2020-08-10 22:44 ` Peter Zijlstra
2020-08-10 21:24 ` [PATCH V6 04/16] tools headers UAPI: Update tools's copy of linux/perf_event.h Kan Liang
2020-08-10 21:24 ` [PATCH V6 05/16] perf record: Support new sample type for data page size Kan Liang
2020-08-10 21:24 ` [PATCH V6 06/16] perf script: Use ULL for enum perf_output_field Kan Liang
2020-08-12 12:21 ` Arnaldo Carvalho de Melo
2020-08-12 13:42 ` Liang, Kan
2020-08-10 21:24 ` [PATCH V6 07/16] perf script: Support data page size Kan Liang
2020-08-10 21:24 ` [PATCH V6 08/16] perf sort: Add sort option for " Kan Liang
2020-08-10 21:24 ` [PATCH V6 09/16] perf mem: Factor out a function to generate sort order Kan Liang
2020-08-10 21:24 ` [PATCH V6 10/16] perf mem: Clean up output format Kan Liang
2020-08-10 21:24 ` [PATCH V6 11/16] perf mem: Support data page size Kan Liang
2020-08-10 21:24 ` [PATCH V6 12/16] perf test: Add test case for PERF_SAMPLE_DATA_PAGE_SIZE Kan Liang
2020-08-10 21:24 ` [PATCH V6 13/16] perf tools: Add support for PERF_SAMPLE_CODE_PAGE_SIZE Kan Liang
2020-08-10 21:24 ` [PATCH V6 14/16] perf script: " Kan Liang
2020-08-10 21:24 ` [PATCH V6 15/16] perf report: " Kan Liang
2020-08-10 21:24 ` [PATCH V6 16/16] perf test: Add test case " Kan Liang
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=20200810224734.GO3982@worktop.programming.kicks-ass.net \
--to=peterz@infradead.org \
--cc=acme@kernel.org \
--cc=ak@linux.intel.com \
--cc=alexander.shishkin@linux.intel.com \
--cc=dave.hansen@intel.com \
--cc=eranian@google.com \
--cc=jolsa@redhat.com \
--cc=kan.liang@linux.intel.com \
--cc=kirill.shutemov@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=mingo@redhat.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.