linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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

  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 \
    --subject='Re: [PATCH v3 11/34] mips: mm: Add p?d_large() definitions' \
    /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

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).