From: Steven Price <steven.price@arm.com>
To: Paul Burton <paul.burton@mips.com>
Cc: "Mark Rutland" <Mark.Rutland@arm.com>,
"Peter Zijlstra" <peterz@infradead.org>,
"Catalin Marinas" <catalin.marinas@arm.com>,
"Dave Hansen" <dave.hansen@linux.intel.com>,
"Will Deacon" <will.deacon@arm.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-mm@kvack.org" <linux-mm@kvack.org>,
"H. Peter Anvin" <hpa@zytor.com>,
"Liang, Kan" <kan.liang@linux.intel.com>,
"x86@kernel.org" <x86@kernel.org>,
"Ingo Molnar" <mingo@redhat.com>,
"James Hogan" <jhogan@kernel.org>,
"Arnd Bergmann" <arnd@arndb.de>,
"Jérôme Glisse" <jglisse@redhat.com>,
"Borislav Petkov" <bp@alien8.de>,
"Andy Lutomirski" <luto@kernel.org>,
"Thomas Gleixner" <tglx@linutronix.de>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
"Ard Biesheuvel" <ard.biesheuvel@linaro.org>,
"linux-mips@vger.kernel.org" <linux-mips@vger.kernel.org>,
"Ralf Baechle" <ralf@linux-mips.org>,
"James Morse" <james.morse@arm.com>
Subject: Re: [PATCH v3 11/34] mips: mm: Add p?d_large() definitions
Date: Fri, 1 Mar 2019 11:02:52 +0000 [thread overview]
Message-ID: <7e314e29-dab5-e941-60c8-05ea74747f4e@arm.com> (raw)
In-Reply-To: <20190228185526.hdryn2zsfign7vht@pburton-laptop>
On 28/02/2019 18:55, Paul Burton wrote:
> Hi Steven,
>
> On Thu, Feb 28, 2019 at 12:11:24PM +0000, Steven Price wrote:
>> On 28/02/2019 02:15, Paul Burton wrote:
>>> On Wed, Feb 27, 2019 at 05:05:45PM +0000, Steven Price wrote:
>>>> For mips, we don't support large pages on 32 bit so add stubs returning 0.
>>>
>>> So far so good :)
>>>
>>>> For 64 bit look for _PAGE_HUGE flag being set. This means exposing the
>>>> flag when !CONFIG_MIPS_HUGE_TLB_SUPPORT.
>>>
>>> Here I have to ask why? We could just return 0 like the mips32 case when
>>> CONFIG_MIPS_HUGE_TLB_SUPPORT=n, let the compiler optimize the whole
>>> thing out and avoid redundant work at runtime.
>>>
>>> This could be unified too in asm/pgtable.h - checking for
>>> CONFIG_MIPS_HUGE_TLB_SUPPORT should be sufficient to cover the mips32
>>> case along with the subset of mips64 configurations without huge pages.
>>
>> The intention here is to define a new set of macros/functions which will
>> always tell us whether we're at the leaf of a page table walk, whether
>> or not huge pages are compiled into the kernel. Basically this allows
>> the page walking code to be used on page tables other than user space,
>> for instance the kernel page tables (which e.g. might use a large
>> mapping for linear memory even if huge pages are not compiled in) or
>> page tables from firmware (e.g. EFI on arm64).
>>
>> I'm not familiar enough with mips to know how it handles things like the
>> linear map so I don't know how relevant that is, but I'm trying to
>> introduce a new set of functions which differ from the existing
>> p?d_huge() macros by not depending on whether these mappings could exist
>> for a user space VMA (i.e. not depending on HUGETLB support and existing
>> for all levels that architecturally they can occur at).
>
> Thanks for the explanation - the background helps.
>
> Right now for MIPS, with one exception, there'll be no difference
> between a page being huge or large. So for the vast majority of kernels
> with CONFIG_MIPS_HUGE_TLB_SUPPORT=n we should just return 0.
>
> The one exception I mentioned is old SGI IP27 support, which allows the
> kernel to be mapped through the TLB & does that using 2x 16MB pages when
> CONFIG_MAPPED_KERNEL=y. However even there your patch as-is won't pick
> up on that for 2 reasons:
>
> 1) The pages in question don't appear to actually be recorded in the
> page tables - they're just written straight into the TLB as wired
> entries (ie. entries that will never be evicted).
>
> 2) Even if they were in the page tables the _PAGE_HUGE bit isn't set.
>
> Since those pages aren't recorded in the page tables anyway we'd either
> need to:
>
> a) Add them to the page tables, and set the _PAGE_HUGE bit.
>
> b) Ignore them if the code you're working on won't be operating on the
> memory mapping the kernel.
>
> For other platforms the kernel is run from unmapped memory, and for all
> cases including IP27 the kernel will use unmapped memory to access
> lowmem or peripherals when possible. That is, MIPS has virtual address
> regions ((c)kseg[01] or xkphys) which are architecturally defined as
> linear maps to physical memory & so VA->PA translation doesn't use the
> TLB at all.
>
> So my thought would be that for almost everything we could just do:
>
> #define pmd_large(pmd) pmd_huge(pmd)
> #define pud_large(pmd) pud_huge(pmd)
>
> And whether we need to do anything about IP27 depends on whether a) or
> b) is chosen above.
>
> Or alternatively you could do something like:
>
> #ifdef _PAGE_HUGE
>
> static inline int pmd_large(pmd_t pmd)
> {
> return (pmd_val(pmd) & _PAGE_HUGE) != 0;
> }
>
> static inline int pud_large(pud_t pud)
> {
> return (pud_val(pud) & _PAGE_HUGE) != 0;
> }
>
> #else
> # define pmd_large(pmd) 0
> # define pud_large(pud) 0
> #endif
>
> That would cover everything except for the IP27, but would make it pick
> up the IP27 kernel pages automatically if someone later defines
> _PAGE_HUGE for IP27 CONFIG_MAPPED_KERNEL=y & makes use of it for those
> pages.
Thanks for the detailed explanation. I think my preference is your
change above (#ifdef _PAGE_HUGE) because I'm trying to stop people
thinking p?d_large==p?d_huge. MIPS is a little different from other
architectures in that the hardware doesn't walk the page tables, so
there isn't a definitive answer as to whether there is a 'huge' bit in
the tables or not - it actually does depend on the kernel configuration.
For the IP27 case I think the current situation is probably fine - the
intention is to walk the page tables, so even though the TLBs (and
therefore the actual translations) might not match, at least p?d_large
will accurately tell when the leaf of the page table tree has been
reached. And as you say, using _PAGE_HUGE as the #ifdef means that
should support be added the code should automatically make use of it.
Thanks for your help,
Steve
next prev parent reply other threads:[~2019-03-01 11:03 UTC|newest]
Thread overview: 68+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-02-27 17:05 [PATCH v3 00/34] Convert x86 & arm64 to use generic page walk Steven Price
2019-02-27 17:05 ` [PATCH v3 01/34] alpha: mm: Add p?d_large() definitions Steven Price
2019-02-27 17:05 ` [PATCH v3 02/34] arc: " Steven Price
2019-02-27 18:18 ` Vineet Gupta
2019-02-27 17:05 ` [PATCH v3 03/34] arm: " Steven Price
2019-03-01 21:47 ` Kirill A. Shutemov
2019-03-04 11:56 ` Steven Price
2019-03-04 13:10 ` Kirill A. Shutemov
2019-02-27 17:05 ` [PATCH v3 04/34] arm64: " Steven Price
2019-02-27 17:05 ` [PATCH v3 05/34] c6x: " Steven Price
2019-03-01 21:48 ` Kirill A. Shutemov
2019-03-04 12:01 ` Steven Price
2019-03-04 13:11 ` Kirill A. Shutemov
2019-02-27 17:05 ` [PATCH v3 06/34] csky: " Steven Price
2019-03-01 21:51 ` Kirill A. Shutemov
2019-02-27 17:05 ` [PATCH v3 07/34] hexagon: " Steven Price
2019-02-27 17:05 ` [PATCH v3 08/34] ia64: " Steven Price
2019-03-01 21:57 ` Kirill A. Shutemov
2019-03-04 13:16 ` Steven Price
2019-03-04 19:06 ` Luck, Tony
2019-03-06 13:45 ` Steven Price
2019-02-27 17:05 ` [PATCH v3 09/34] m68k: " Steven Price
2019-02-27 19:27 ` Geert Uytterhoeven
2019-02-28 11:36 ` Mike Rapoport
2019-02-28 11:53 ` Geert Uytterhoeven
2019-02-28 12:04 ` Steven Price
2019-03-01 11:45 ` Mike Rapoport
2019-02-27 17:05 ` [PATCH v3 10/34] microblaze: " Steven Price
2019-02-27 17:05 ` [PATCH v3 11/34] mips: " Steven Price
2019-02-28 2:15 ` Paul Burton
2019-02-28 12:11 ` Steven Price
2019-02-28 18:55 ` Paul Burton
2019-03-01 11:02 ` Steven Price [this message]
2019-02-27 17:05 ` [PATCH v3 12/34] nds32: " Steven Price
2019-02-27 17:05 ` [PATCH v3 13/34] nios2: " Steven Price
2019-02-27 17:05 ` [PATCH v3 14/34] openrisc: " Steven Price
2019-02-27 17:05 ` [PATCH v3 15/34] parisc: " Steven Price
2019-02-27 18:54 ` Helge Deller
2019-03-01 22:12 ` Kirill A. Shutemov
2019-03-05 21:45 ` Helge Deller
2019-02-27 17:05 ` [PATCH v3 16/34] powerpc: " Steven Price
2019-02-27 17:05 ` [PATCH v3 17/34] riscv: " Steven Price
2019-02-27 17:05 ` [PATCH v3 18/34] s390: " Steven Price
2019-02-27 17:40 ` Martin Schwidefsky
2019-02-28 11:43 ` Steven Price
2019-02-27 17:05 ` [PATCH v3 19/34] sh: " Steven Price
2019-02-27 17:05 ` [PATCH v3 20/34] sparc: " Steven Price
2019-02-27 18:38 ` David Miller
2019-02-28 11:49 ` Steven Price
2019-02-27 17:05 ` [PATCH v3 21/34] um: " Steven Price
2019-02-27 17:05 ` [PATCH v3 22/34] unicore32: " Steven Price
2019-02-27 17:05 ` [PATCH v3 23/34] xtensa: " Steven Price
2019-02-27 17:29 ` Max Filippov
2019-02-27 17:05 ` [PATCH v3 24/34] mm: Add generic p?d_large() macros Steven Price
2019-02-27 17:05 ` [PATCH v3 25/34] mm: pagewalk: Add p4d_entry() and pgd_entry() Steven Price
2019-02-27 17:06 ` [PATCH v3 26/34] mm: pagewalk: Allow walking without vma Steven Price
2019-02-27 17:06 ` [PATCH v3 27/34] mm: pagewalk: Add 'depth' parameter to pte_hole Steven Price
2019-02-27 17:38 ` Dave Hansen
2019-02-28 11:28 ` Steven Price
2019-02-28 19:00 ` Dave Hansen
2019-03-01 11:24 ` Steven Price
2019-02-27 17:06 ` [PATCH v3 28/34] mm: pagewalk: Add test_p?d callbacks Steven Price
2019-02-27 17:06 ` [PATCH v3 29/34] arm64: mm: Convert mm/dump.c to use walk_page_range() Steven Price
2019-02-27 17:06 ` [PATCH v3 30/34] x86/mm: Point to struct seq_file from struct pg_state Steven Price
2019-02-27 17:06 ` [PATCH v3 31/34] x86/mm+efi: Convert ptdump_walk_pgd_level() to take a mm_struct Steven Price
2019-02-27 17:06 ` [PATCH v3 32/34] x86/mm: Convert ptdump_walk_pgd_level_debugfs() to take an mm_struct Steven Price
2019-02-27 17:06 ` [PATCH v3 33/34] x86/mm: Convert ptdump_walk_pgd_level_core() " Steven Price
2019-02-27 17:06 ` [PATCH v3 34/34] x86: mm: Convert dump_pagetables to use walk_page_range Steven Price
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=7e314e29-dab5-e941-60c8-05ea74747f4e@arm.com \
--to=steven.price@arm.com \
--cc=Mark.Rutland@arm.com \
--cc=ard.biesheuvel@linaro.org \
--cc=arnd@arndb.de \
--cc=bp@alien8.de \
--cc=catalin.marinas@arm.com \
--cc=dave.hansen@linux.intel.com \
--cc=hpa@zytor.com \
--cc=james.morse@arm.com \
--cc=jglisse@redhat.com \
--cc=jhogan@kernel.org \
--cc=kan.liang@linux.intel.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mips@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=luto@kernel.org \
--cc=mingo@redhat.com \
--cc=paul.burton@mips.com \
--cc=peterz@infradead.org \
--cc=ralf@linux-mips.org \
--cc=tglx@linutronix.de \
--cc=will.deacon@arm.com \
--cc=x86@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).