[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 11 Nov 2020 16:57:24 +0100
From: Peter Zijlstra <peterz@...radead.org>
To: Matthew Wilcox <willy@...radead.org>
Cc: "Liang, Kan" <kan.liang@...ux.intel.com>,
Will Deacon <will@...nel.org>,
Michael Ellerman <mpe@...erman.id.au>, mingo@...hat.com,
acme@...nel.org, linux-kernel@...r.kernel.org,
mark.rutland@....com, alexander.shishkin@...ux.intel.com,
jolsa@...hat.com, eranian@...gle.com, ak@...ux.intel.com,
dave.hansen@...el.com, kirill.shutemov@...ux.intel.com,
benh@...nel.crashing.org, paulus@...ba.org,
David Miller <davem@...emloft.net>, vbabka@...e.cz
Subject: Re: [PATCH V9 1/4] perf/core: Add PERF_SAMPLE_DATA_PAGE_SIZE
On Wed, Nov 11, 2020 at 03:30:22PM +0000, Matthew Wilcox wrote:
> This confuses me. Why only special-case hugetlbfs pages here? Should
> they really be treated differently from THP? If you want to consider
> that we might be mapping a page that's twice as big as a PUD entry and
> this is only half of it, then the simple way is:
>
> if (pud_leaf(pud)) {
> #ifdef pud_page
> page = compound_head(pud_page(*pud));
> return page_size(page);
Also; this is 'wrong'. The purpose of this function is to return the
hardware TLB size of a given address. The above will return the compound
size, for any random compound page, which would be myrads of reasons.
So the PageHuge() thing tells us it is a HugeTLB page and those are
(barring hardware TLB promotion/demotion) guaranteed to reflect the
actual TLB size.
> #else
> return 1ULL << PUD_SHIFT;
> #endif
> }
Powered by blists - more mailing lists