From: Peter Zijlstra <peterz@infradead.org>
To: Christophe Leroy <christophe.leroy@csgroup.eu>
Cc: kan.liang@linux.intel.com, mingo@kernel.org, acme@kernel.org,
mark.rutland@arm.com, alexander.shishkin@linux.intel.com,
jolsa@redhat.com, eranian@google.com, npiggin@gmail.com,
linuxppc-dev@lists.ozlabs.org, mpe@ellerman.id.au,
will@kernel.org, willy@infradead.org, aneesh.kumar@linux.ibm.com,
sparclinux@vger.kernel.org, davem@davemloft.net,
catalin.marinas@arm.com, linux-arch@vger.kernel.org,
linux-kernel@vger.kernel.org, ak@linux.intel.com,
dave.hansen@intel.com, kirill.shutemov@linux.intel.com
Subject: Re: [PATCH 0/5] perf/mm: Fix PERF_SAMPLE_*_PAGE_SIZE
Date: Fri, 20 Nov 2020 13:20:04 +0100 [thread overview]
Message-ID: <20201120122004.GG3021@hirez.programming.kicks-ass.net> (raw)
In-Reply-To: <2a32b00b-2214-3283-58e0-9cb0ff4bd728@csgroup.eu>
On Fri, Nov 20, 2020 at 12:18:22PM +0100, Christophe Leroy wrote:
> Hi Peter,
>
> Le 13/11/2020 à 14:44, Christophe Leroy a écrit :
> > Hi
> >
> > Le 13/11/2020 à 12:19, Peter Zijlstra a écrit :
> > > Hi,
> > >
> > > These patches provide generic infrastructure to determine TLB page size from
> > > page table entries alone. Perf will use this (for either data or code address)
> > > to aid in profiling TLB issues.
> > >
> > > While most architectures only have page table aligned large pages, some
> > > (notably ARM64, Sparc64 and Power) provide non page table aligned large pages
> > > and need to provide their own implementation of these functions.
> > >
> > > I've provided (completely untested) implementations for ARM64 and Sparc64, but
> > > failed to penetrate the _many_ Power MMUs. I'm hoping Nick or Aneesh can help
> > > me out there.
> > >
> >
> > I can help with powerpc 8xx. It is a 32 bits powerpc. The PGD has 1024
> > entries, that means each entry maps 4M.
> >
> > Page sizes are 4k, 16k, 512k and 8M.
> >
> > For the 8M pages we use hugepd with a single entry. The two related PGD
> > entries point to the same hugepd.
> >
> > For the other sizes, they are in standard page tables. 16k pages appear
> > 4 times in the page table. 512k entries appear 128 times in the page
> > table.
> >
> > When the PGD entry has _PMD_PAGE_8M bits, the PMD entry points to a
> > hugepd with holds the single 8M entry.
> >
> > In the PTE, we have two bits: _PAGE_SPS and _PAGE_HUGE
> >
> > _PAGE_HUGE means it is a 512k page
> > _PAGE_SPS means it is not a 4k page
> >
> > The kernel can by build either with 4k pages as standard page size, or
> > 16k pages. It doesn't change the page table layout though.
> >
> > Hope this is clear. Now I don't really know to wire that up to your series.
>
> Does my description make sense ? Is there anything I can help with ?
It did, and I had vague memories from when we fixed that pgd_t issue.
I've just not had time to dig through the powerpc code yet to find the
right mmu header to stick it in.
I was meaning to get another version of these patches posted this week,
but time keeps slipping away, I'll try.
WARNING: multiple messages have this Message-ID (diff)
From: Peter Zijlstra <peterz@infradead.org>
To: Christophe Leroy <christophe.leroy@csgroup.eu>
Cc: kan.liang@linux.intel.com, mingo@kernel.org, acme@kernel.org,
mark.rutland@arm.com, alexander.shishkin@linux.intel.com,
jolsa@redhat.com, eranian@google.com, npiggin@gmail.com,
linuxppc-dev@lists.ozlabs.org, mpe@ellerman.id.au,
will@kernel.org, willy@infradead.org, aneesh.kumar@linux.ibm.com,
sparclinux@vger.kernel.org, davem@davemloft.net,
catalin.marinas@arm.com, linux-arch@vger.kernel.org,
linux-kernel@vger.kernel.org, ak@linux.intel.com,
dave.hansen@intel.com, kirill.shutemov@linux.intel.com
Subject: Re: [PATCH 0/5] perf/mm: Fix PERF_SAMPLE_*_PAGE_SIZE
Date: Fri, 20 Nov 2020 12:20:04 +0000 [thread overview]
Message-ID: <20201120122004.GG3021@hirez.programming.kicks-ass.net> (raw)
In-Reply-To: <2a32b00b-2214-3283-58e0-9cb0ff4bd728@csgroup.eu>
On Fri, Nov 20, 2020 at 12:18:22PM +0100, Christophe Leroy wrote:
> Hi Peter,
>
> Le 13/11/2020 à 14:44, Christophe Leroy a écrit :
> > Hi
> >
> > Le 13/11/2020 à 12:19, Peter Zijlstra a écrit :
> > > Hi,
> > >
> > > These patches provide generic infrastructure to determine TLB page size from
> > > page table entries alone. Perf will use this (for either data or code address)
> > > to aid in profiling TLB issues.
> > >
> > > While most architectures only have page table aligned large pages, some
> > > (notably ARM64, Sparc64 and Power) provide non page table aligned large pages
> > > and need to provide their own implementation of these functions.
> > >
> > > I've provided (completely untested) implementations for ARM64 and Sparc64, but
> > > failed to penetrate the _many_ Power MMUs. I'm hoping Nick or Aneesh can help
> > > me out there.
> > >
> >
> > I can help with powerpc 8xx. It is a 32 bits powerpc. The PGD has 1024
> > entries, that means each entry maps 4M.
> >
> > Page sizes are 4k, 16k, 512k and 8M.
> >
> > For the 8M pages we use hugepd with a single entry. The two related PGD
> > entries point to the same hugepd.
> >
> > For the other sizes, they are in standard page tables. 16k pages appear
> > 4 times in the page table. 512k entries appear 128 times in the page
> > table.
> >
> > When the PGD entry has _PMD_PAGE_8M bits, the PMD entry points to a
> > hugepd with holds the single 8M entry.
> >
> > In the PTE, we have two bits: _PAGE_SPS and _PAGE_HUGE
> >
> > _PAGE_HUGE means it is a 512k page
> > _PAGE_SPS means it is not a 4k page
> >
> > The kernel can by build either with 4k pages as standard page size, or
> > 16k pages. It doesn't change the page table layout though.
> >
> > Hope this is clear. Now I don't really know to wire that up to your series.
>
> Does my description make sense ? Is there anything I can help with ?
It did, and I had vague memories from when we fixed that pgd_t issue.
I've just not had time to dig through the powerpc code yet to find the
right mmu header to stick it in.
I was meaning to get another version of these patches posted this week,
but time keeps slipping away, I'll try.
WARNING: multiple messages have this Message-ID (diff)
From: Peter Zijlstra <peterz@infradead.org>
To: Christophe Leroy <christophe.leroy@csgroup.eu>
Cc: mark.rutland@arm.com, aneesh.kumar@linux.ibm.com,
willy@infradead.org, catalin.marinas@arm.com, will@kernel.org,
alexander.shishkin@linux.intel.com,
linuxppc-dev@lists.ozlabs.org, npiggin@gmail.com,
linux-kernel@vger.kernel.org, acme@kernel.org,
davem@davemloft.net, dave.hansen@intel.com, ak@linux.intel.com,
eranian@google.com, sparclinux@vger.kernel.org,
linux-arch@vger.kernel.org, jolsa@redhat.com, mingo@kernel.org,
kirill.shutemov@linux.intel.com, kan.liang@linux.intel.com
Subject: Re: [PATCH 0/5] perf/mm: Fix PERF_SAMPLE_*_PAGE_SIZE
Date: Fri, 20 Nov 2020 13:20:04 +0100 [thread overview]
Message-ID: <20201120122004.GG3021@hirez.programming.kicks-ass.net> (raw)
In-Reply-To: <2a32b00b-2214-3283-58e0-9cb0ff4bd728@csgroup.eu>
On Fri, Nov 20, 2020 at 12:18:22PM +0100, Christophe Leroy wrote:
> Hi Peter,
>
> Le 13/11/2020 à 14:44, Christophe Leroy a écrit :
> > Hi
> >
> > Le 13/11/2020 à 12:19, Peter Zijlstra a écrit :
> > > Hi,
> > >
> > > These patches provide generic infrastructure to determine TLB page size from
> > > page table entries alone. Perf will use this (for either data or code address)
> > > to aid in profiling TLB issues.
> > >
> > > While most architectures only have page table aligned large pages, some
> > > (notably ARM64, Sparc64 and Power) provide non page table aligned large pages
> > > and need to provide their own implementation of these functions.
> > >
> > > I've provided (completely untested) implementations for ARM64 and Sparc64, but
> > > failed to penetrate the _many_ Power MMUs. I'm hoping Nick or Aneesh can help
> > > me out there.
> > >
> >
> > I can help with powerpc 8xx. It is a 32 bits powerpc. The PGD has 1024
> > entries, that means each entry maps 4M.
> >
> > Page sizes are 4k, 16k, 512k and 8M.
> >
> > For the 8M pages we use hugepd with a single entry. The two related PGD
> > entries point to the same hugepd.
> >
> > For the other sizes, they are in standard page tables. 16k pages appear
> > 4 times in the page table. 512k entries appear 128 times in the page
> > table.
> >
> > When the PGD entry has _PMD_PAGE_8M bits, the PMD entry points to a
> > hugepd with holds the single 8M entry.
> >
> > In the PTE, we have two bits: _PAGE_SPS and _PAGE_HUGE
> >
> > _PAGE_HUGE means it is a 512k page
> > _PAGE_SPS means it is not a 4k page
> >
> > The kernel can by build either with 4k pages as standard page size, or
> > 16k pages. It doesn't change the page table layout though.
> >
> > Hope this is clear. Now I don't really know to wire that up to your series.
>
> Does my description make sense ? Is there anything I can help with ?
It did, and I had vague memories from when we fixed that pgd_t issue.
I've just not had time to dig through the powerpc code yet to find the
right mmu header to stick it in.
I was meaning to get another version of these patches posted this week,
but time keeps slipping away, I'll try.
next prev parent reply other threads:[~2020-11-20 12:20 UTC|newest]
Thread overview: 55+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-11-13 11:19 [PATCH 0/5] perf/mm: Fix PERF_SAMPLE_*_PAGE_SIZE Peter Zijlstra
2020-11-13 11:19 ` Peter Zijlstra
2020-11-13 11:19 ` Peter Zijlstra
2020-11-13 11:19 ` [PATCH 1/5] mm/gup: Provide gup_get_pte() more generic Peter Zijlstra
2020-11-13 11:19 ` Peter Zijlstra
2020-11-13 11:19 ` Peter Zijlstra
2020-11-13 11:19 ` [PATCH 2/5] mm: Introduce pXX_leaf_size() Peter Zijlstra
2020-11-13 11:19 ` Peter Zijlstra
2020-11-13 11:19 ` Peter Zijlstra
2020-11-13 11:45 ` Peter Zijlstra
2020-11-13 11:45 ` Peter Zijlstra
2020-11-13 11:45 ` Peter Zijlstra
2020-11-13 11:19 ` [PATCH 3/5] perf/core: Fix arch_perf_get_page_size() Peter Zijlstra
2020-11-13 11:19 ` Peter Zijlstra
2020-11-13 11:19 ` Peter Zijlstra
2020-11-16 13:11 ` Liang, Kan
2020-11-16 13:11 ` Liang, Kan
2020-11-16 13:11 ` Liang, Kan
2020-11-13 11:19 ` [PATCH 4/5] arm64/mm: Implement pXX_leaf_size() support Peter Zijlstra
2020-11-13 11:19 ` Peter Zijlstra
2020-11-13 11:19 ` Peter Zijlstra
2020-11-13 11:19 ` [PATCH 5/5] sparc64/mm: " Peter Zijlstra
2020-11-13 11:19 ` Peter Zijlstra
2020-11-13 11:19 ` Peter Zijlstra
2020-11-13 13:44 ` [PATCH 0/5] perf/mm: Fix PERF_SAMPLE_*_PAGE_SIZE Christophe Leroy
2020-11-13 13:44 ` Christophe Leroy
2020-11-13 13:44 ` Christophe Leroy
2020-11-20 11:18 ` Christophe Leroy
2020-11-20 11:18 ` Christophe Leroy
2020-11-20 11:18 ` Christophe Leroy
2020-11-20 12:20 ` Peter Zijlstra [this message]
2020-11-20 12:20 ` Peter Zijlstra
2020-11-20 12:20 ` Peter Zijlstra
2020-11-26 10:46 ` Peter Zijlstra
2020-11-26 10:46 ` Peter Zijlstra
2020-11-26 10:46 ` Peter Zijlstra
2020-11-16 15:43 ` Kirill A. Shutemov
2020-11-16 15:43 ` Kirill A. Shutemov
2020-11-16 15:43 ` Kirill A. Shutemov
2020-11-16 15:54 ` Matthew Wilcox
2020-11-16 15:54 ` Matthew Wilcox
2020-11-16 16:28 ` Dave Hansen
2020-11-16 16:28 ` Dave Hansen
2020-11-16 16:28 ` Dave Hansen
2020-11-16 16:32 ` Matthew Wilcox
2020-11-16 16:32 ` Matthew Wilcox
2020-11-16 16:36 ` Dave Hansen
2020-11-16 16:36 ` Dave Hansen
2020-11-16 16:36 ` Dave Hansen
2020-11-16 16:57 ` Peter Zijlstra
2020-11-16 16:57 ` Peter Zijlstra
2020-11-16 16:57 ` Peter Zijlstra
2020-11-16 16:55 ` Peter Zijlstra
2020-11-16 16:55 ` Peter Zijlstra
2020-11-16 16:55 ` Peter Zijlstra
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=20201120122004.GG3021@hirez.programming.kicks-ass.net \
--to=peterz@infradead.org \
--cc=acme@kernel.org \
--cc=ak@linux.intel.com \
--cc=alexander.shishkin@linux.intel.com \
--cc=aneesh.kumar@linux.ibm.com \
--cc=catalin.marinas@arm.com \
--cc=christophe.leroy@csgroup.eu \
--cc=dave.hansen@intel.com \
--cc=davem@davemloft.net \
--cc=eranian@google.com \
--cc=jolsa@redhat.com \
--cc=kan.liang@linux.intel.com \
--cc=kirill.shutemov@linux.intel.com \
--cc=linux-arch@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=mark.rutland@arm.com \
--cc=mingo@kernel.org \
--cc=mpe@ellerman.id.au \
--cc=npiggin@gmail.com \
--cc=sparclinux@vger.kernel.org \
--cc=will@kernel.org \
--cc=willy@infradead.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 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.