From: Anshuman Khandual <anshuman.khandual@arm.com>
To: "Russell King (Oracle)" <linux@armlinux.org.uk>
Cc: linux-mm@kvack.org, akpm@linux-foundation.org,
linux-kernel@vger.kernel.org, geert@linux-m68k.org,
Christoph Hellwig <hch@infradead.org>,
linuxppc-dev@lists.ozlabs.org,
linux-arm-kernel@lists.infradead.org, sparclinux@vger.kernel.org,
linux-mips@vger.kernel.org, linux-m68k@lists.linux-m68k.org,
linux-s390@vger.kernel.org, linux-riscv@lists.infradead.org,
linux-alpha@vger.kernel.org, linux-sh@vger.kernel.org,
linux-snps-arc@lists.infradead.org, linux-csky@vger.kernel.org,
linux-xtensa@linux-xtensa.org, linux-parisc@vger.kernel.org,
openrisc@lists.librecores.org, linux-um@lists.infradead.org,
linux-hexagon@vger.kernel.org, linux-ia64@vger.kernel.org,
linux-arch@vger.kernel.org, Arnd Bergmann <arnd@arndb.de>
Subject: Re: [PATCH V3 09/30] arm/mm: Enable ARCH_HAS_VM_GET_PAGE_PROT
Date: Tue, 1 Mar 2022 05:30:41 +0530 [thread overview]
Message-ID: <542fa048-131e-240b-cc3a-fd4fff7ce4ba@arm.com> (raw)
In-Reply-To: <Yhyqjo/4bozJB6j5@shell.armlinux.org.uk>
On 2/28/22 4:27 PM, Russell King (Oracle) wrote:
> On Mon, Feb 28, 2022 at 04:17:32PM +0530, Anshuman Khandual wrote:
>> This defines and exports a platform specific custom vm_get_page_prot() via
>> subscribing ARCH_HAS_VM_GET_PAGE_PROT. Subsequently all __SXXX and __PXXX
>> macros can be dropped which are no longer needed.
>
> What I would really like to know is why having to run _code_ to work out
> what the page protections need to be is better than looking it up in a
> table.
>
> Not only is this more expensive in terms of CPU cycles, it also brings
> additional code size with it.
>
> I'm struggling to see what the benefit is.
>
Currently vm_get_page_prot() is also being _run_ to fetch required page
protection values. Although that is being run in the core MM and from a
platform perspective __SXXX, __PXXX are just being exported for a table.
Looking it up in a table (and applying more constructs there after) is
not much different than a clean switch case statement in terms of CPU
usage. So this is not more expensive in terms of CPU cycles.
--------------------------
pgprot_t protection_map[16] __ro_after_init = {
__P000, __P001, __P010, __P011, __P100, __P101, __P110, __P111,
__S000, __S001, __S010, __S011, __S100, __S101, __S110, __S111
};
#ifndef CONFIG_ARCH_HAS_FILTER_PGPROT
static inline pgprot_t arch_filter_pgprot(pgprot_t prot)
{
return prot;
}
#endif
pgprot_t vm_get_page_prot(unsigned long vm_flags)
{
pgprot_t ret = __pgprot(pgprot_val(protection_map[vm_flags &
(VM_READ|VM_WRITE|VM_EXEC|VM_SHARED)]) |
pgprot_val(arch_vm_get_page_prot(vm_flags)));
return arch_filter_pgprot(ret);
}
EXPORT_SYMBOL(vm_get_page_prot)
----------------------------
There will be a single vm_get_page_prot() instance on a given platform
just like before. So this also does not bring any additional code size
with it.
As mentioned earlier on a previous version.
Remove multiple 'core MM <--> platform' abstraction layers to map
vm_flags access permission combination into page protection.
From the cover letter ......
----------
Currently there are multiple layers of abstraction i.e __SXXX/__PXXX macros
, protection_map[], arch_vm_get_page_prot() and arch_filter_pgprot() built
between the platform and generic MM, finally defining vm_get_page_prot().
Hence this series proposes to drop all these abstraction levels and instead
just move the responsibility of defining vm_get_page_prot() to the platform
itself making it clean and simple.
----------
Benefits
1. For platforms using arch_vm_get_page_prot() and/or arch_filter_pgprot()
- A simplified vm_get_page_prot()
- Dropped arch_vm_get_page_prot() and arch_filter_pgprot()
- Dropped __SXXX, __PXXX macros
2. For platforms which just exported __SXXX, __PXXX
- A simplified vm_get_page_prot()
- Dropped __SXXX, __PXXX macros
3. For core MM
- Dropped a complex vm_get_page_prot() with multiple layers
of abstraction i.e __SXXX/__PXXX macros, protection_map[],
arch_vm_get_page_prot(), arch_filter_pgprot() etc.
- Anshuman
next prev parent reply other threads:[~2022-03-01 0:00 UTC|newest]
Thread overview: 50+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-02-28 10:47 [PATCH V3 00/30] mm/mmap: Drop protection_map[] and platform's __SXXX/__PXXX requirements Anshuman Khandual
2022-02-28 10:47 ` [PATCH V3 01/30] mm/debug_vm_pgtable: Drop protection_map[] usage Anshuman Khandual
2022-02-28 10:47 ` [PATCH V3 02/30] mm/mmap: Clarify protection_map[] indices Anshuman Khandual
2022-02-28 10:47 ` [PATCH V3 03/30] mm/mmap: Add new config ARCH_HAS_VM_GET_PAGE_PROT Anshuman Khandual
2022-02-28 10:47 ` [PATCH V3 04/30] powerpc/mm: Enable ARCH_HAS_VM_GET_PAGE_PROT Anshuman Khandual
2022-03-02 5:23 ` Michael Ellerman
2022-02-28 10:47 ` [PATCH V3 05/30] arm64/mm: " Anshuman Khandual
2022-03-03 15:28 ` Catalin Marinas
2022-03-09 11:31 ` Anshuman Khandual
2022-02-28 10:47 ` [PATCH V3 06/30] sparc/mm: " Anshuman Khandual
2022-02-28 10:47 ` [PATCH V3 07/30] mips/mm: " Anshuman Khandual
2022-02-28 10:47 ` [PATCH V3 08/30] m68k/mm: " Anshuman Khandual
2022-02-28 10:47 ` [PATCH V3 09/30] arm/mm: " Anshuman Khandual
2022-02-28 10:57 ` Russell King (Oracle)
2022-02-28 13:49 ` Geert Uytterhoeven
2022-03-01 0:00 ` Anshuman Khandual [this message]
2022-03-01 0:31 ` Russell King (Oracle)
2022-03-01 8:16 ` Christophe Leroy
2022-03-02 3:22 ` Anshuman Khandual
2022-03-02 7:05 ` Christophe Leroy
2022-03-02 9:51 ` Anshuman Khandual
2022-03-02 10:05 ` Geert Uytterhoeven
2022-03-02 11:06 ` Anshuman Khandual
2022-03-02 11:14 ` Geert Uytterhoeven
2022-03-09 11:33 ` Anshuman Khandual
2022-03-02 11:19 ` Russell King (Oracle)
2022-03-02 3:15 ` Anshuman Khandual
2022-02-28 10:47 ` [PATCH V3 10/30] x86/mm: " Anshuman Khandual
2022-02-28 10:47 ` [PATCH V3 11/30] mm/mmap: Drop protection_map[] Anshuman Khandual
2022-02-28 10:47 ` [PATCH V3 12/30] mm/mmap: Drop arch_filter_pgprot() Anshuman Khandual
2022-02-28 10:47 ` [PATCH V3 13/30] mm/mmap: Drop arch_vm_get_page_pgprot() Anshuman Khandual
2022-02-28 10:47 ` [PATCH V3 14/30] s390/mm: Enable ARCH_HAS_VM_GET_PAGE_PROT Anshuman Khandual
2022-02-28 10:47 ` [PATCH V3 15/30] riscv/mm: " Anshuman Khandual
2022-02-28 10:47 ` [PATCH V3 16/30] alpha/mm: " Anshuman Khandual
2022-02-28 10:47 ` [PATCH V3 17/30] sh/mm: " Anshuman Khandual
2022-02-28 10:47 ` [PATCH V3 18/30] arc/mm: " Anshuman Khandual
2022-02-28 10:47 ` [PATCH V3 19/30] csky/mm: " Anshuman Khandual
2022-03-01 14:00 ` Guo Ren
2022-02-28 10:47 ` [PATCH V3 20/30] xtensa/mm: " Anshuman Khandual
2022-02-28 10:47 ` [PATCH V3 21/30] parisc/mm: " Anshuman Khandual
2022-02-28 10:47 ` [PATCH V3 22/30] openrisc/mm: " Anshuman Khandual
2022-02-28 10:47 ` [PATCH V3 23/30] um/mm: " Anshuman Khandual
2022-02-28 10:47 ` [PATCH V3 24/30] microblaze/mm: " Anshuman Khandual
2022-02-28 10:47 ` [PATCH V3 25/30] nios2/mm: " Anshuman Khandual
2022-02-28 10:47 ` [PATCH V3 26/30] hexagon/mm: " Anshuman Khandual
2022-02-28 10:47 ` [PATCH V3 27/30] nds32/mm: " Anshuman Khandual
2022-02-28 10:47 ` [PATCH V3 28/30] ia64/mm: " Anshuman Khandual
2022-02-28 10:47 ` [PATCH V3 29/30] mm/mmap: Drop generic vm_get_page_prot() Anshuman Khandual
2022-02-28 10:47 ` [PATCH V3 30/30] mm/mmap: Drop ARCH_HAS_VM_GET_PAGE_PROT Anshuman Khandual
2022-03-09 10:59 ` [PATCH V3 00/30] mm/mmap: Drop protection_map[] and platform's __SXXX/__PXXX requirements Anshuman Khandual
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=542fa048-131e-240b-cc3a-fd4fff7ce4ba@arm.com \
--to=anshuman.khandual@arm.com \
--cc=akpm@linux-foundation.org \
--cc=arnd@arndb.de \
--cc=geert@linux-m68k.org \
--cc=hch@infradead.org \
--cc=linux-alpha@vger.kernel.org \
--cc=linux-arch@vger.kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-csky@vger.kernel.org \
--cc=linux-hexagon@vger.kernel.org \
--cc=linux-ia64@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-m68k@lists.linux-m68k.org \
--cc=linux-mips@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-parisc@vger.kernel.org \
--cc=linux-riscv@lists.infradead.org \
--cc=linux-s390@vger.kernel.org \
--cc=linux-sh@vger.kernel.org \
--cc=linux-snps-arc@lists.infradead.org \
--cc=linux-um@lists.infradead.org \
--cc=linux-xtensa@linux-xtensa.org \
--cc=linux@armlinux.org.uk \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=openrisc@lists.librecores.org \
--cc=sparclinux@vger.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