public inbox for linux-hexagon@vger.kernel.org
 help / color / mirror / Atom feed
From: "Arnd Bergmann" <arnd@arndb.de>
To: "Geert Uytterhoeven" <geert@linux-m68k.org>
Cc: "Arnd Bergmann" <arnd@kernel.org>,
	"Thomas Gleixner" <tglx@linutronix.de>,
	"Vincenzo Frascino" <vincenzo.frascino@arm.com>,
	"Kees Cook" <keescook@chromium.org>,
	"Anna-Maria Gleixner" <anna-maria@linutronix.de>,
	"Matt Turner" <mattst88@gmail.com>,
	"Vineet Gupta" <vgupta@kernel.org>,
	"Russell King" <linux@armlinux.org.uk>,
	"Catalin Marinas" <catalin.marinas@arm.com>,
	guoren <guoren@kernel.org>, "Brian Cain" <bcain@quicinc.com>,
	"Huacai Chen" <chenhuacai@kernel.org>,
	"Michal Simek" <monstr@monstr.eu>,
	"Thomas Bogendoerfer" <tsbogend@alpha.franken.de>,
	"Helge Deller" <deller@gmx.de>,
	"Michael Ellerman" <mpe@ellerman.id.au>,
	"Christophe Leroy" <christophe.leroy@csgroup.eu>,
	"Palmer Dabbelt" <palmer@dabbelt.com>,
	"John Paul Adrian Glaubitz" <glaubitz@physik.fu-berlin.de>,
	"Andreas Larsson" <andreas@gaisler.com>,
	"Richard Weinberger" <richard@nod.at>,
	x86@kernel.org, "Max Filippov" <jcmvbkbc@gmail.com>,
	"Andy Lutomirski" <luto@kernel.org>,
	"Jan Kiszka" <jan.kiszka@siemens.com>,
	"Kieran Bingham" <kbingham@kernel.org>,
	"Andrew Morton" <akpm@linux-foundation.org>,
	linux-kernel@vger.kernel.org, linux-alpha@vger.kernel.org,
	linux-snps-arc@lists.infradead.org,
	linux-arm-kernel@lists.infradead.org,
	"linux-csky@vger.kernel.org" <linux-csky@vger.kernel.org>,
	linux-hexagon@vger.kernel.org, loongarch@lists.linux.dev,
	linux-m68k@lists.linux-m68k.org, linux-mips@vger.kernel.org,
	"linux-openrisc@vger.kernel.org" <linux-openrisc@vger.kernel.org>,
	linux-parisc@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
	linux-riscv@lists.infradead.org, linux-s390@vger.kernel.org,
	linux-sh@vger.kernel.org, sparclinux@vger.kernel.org,
	linux-um@lists.infradead.org,
	"Greg Ungerer" <gerg@linux-m68k.org>
Subject: Re: [PATCH 3/4] arch: define CONFIG_PAGE_SIZE_*KB on all architectures
Date: Tue, 27 Feb 2024 15:18:38 +0100	[thread overview]
Message-ID: <7b62e73d-d3fa-4432-807d-c2e667814b17@app.fastmail.com> (raw)
In-Reply-To: <CAMuHMdXQYPtL0J4Phm81S1qWpi7no=1r4uStbLd8zbjn7fcWQw@mail.gmail.com>

On Tue, Feb 27, 2024, at 12:12, Geert Uytterhoeven wrote:
> On Tue, Feb 27, 2024 at 11:59 AM Arnd Bergmann <arnd@arndb.de> wrote:
>> On Tue, Feb 27, 2024, at 09:54, Geert Uytterhoeven wrote:
>> I was a bit unsure about how to best do this since there
>> is not really a need for a fixed page size on nommu kernels,
>> whereas the three MMU configs clearly tie the page size to
>> the MMU rather than the platform.
>>
>> There should be no reason for coldfire to have a different
>> page size from dragonball if neither of them actually uses
>> hardware pages, so one of them could be changed later.
>
> Indeed, in theory, PAGE_SIZE doesn't matter for nommu, but the concept
> of pages is used all over the place in Linux.
>
> I'm mostly worried about some Coldfire code relying on the actual value
> of PAGE_SIZE in some other context. e.g. for configuring non-cacheable
> regions.

Right, any change here would have to be carefully tested. I would
expect that a 4K page size would reduce memory consumption even on
NOMMU systems that should have the same tradeoffs for representing
files in the page cache and in mem_map[].

> And does this impact running nommu binaries on a system with MMU?
> I.e. if nommu binaries were built with a 4 KiB PAGE_SIZE, do they
> still run on MMU systems with an 8 KiB PAGE_SIZE (coldfire and sun3),
> or are there some subtleties to take into account?

As far as I understand, binaries have to be built and linked for
the largest page size they can run on, so running them on a kernel
with smaller page size usually works.

One notable exception is sys_mmap2(), which on most architectures
takes units of 4KiB but on m68k is actually written to take
PAGE_SIZE units. As Al pointed out in f8b7256096a2 ("Unify
sys_mmap*"), it has always been wrong on sun3, presumably
because users of that predate modern glibc. Running coldfire
nommu binaries on coldfire mmu kernels would run into the same
bug if either of them changes PAGE_SIZE. If you can run
coldfire nommu binaries on classic m68k, that is already
broken in the same way.

      Arnd

  reply	other threads:[~2024-02-27 14:19 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-02-26 16:14 [PATCH 0/4] arch: mm, vdso: consolidate PAGE_SIZE definition Arnd Bergmann
2024-02-26 16:14 ` [PATCH 1/4] arch: consolidate existing CONFIG_PAGE_SIZE_*KB definitions Arnd Bergmann
2024-02-26 16:55   ` Samuel Holland
2024-02-27 15:40     ` Arnd Bergmann
2024-02-27 15:44       ` Christophe Leroy
2024-02-27 15:48         ` Arnd Bergmann
2024-02-26 19:02   ` Christophe Leroy
2024-02-27 15:42     ` Arnd Bergmann
2024-02-27  8:45   ` Geert Uytterhoeven
2024-02-27 15:43     ` Arnd Bergmann
2024-02-26 16:14 ` [PATCH 2/4] arch: simplify architecture specific page size configuration Arnd Bergmann
2024-02-26 19:05   ` Christophe Leroy
2024-02-27 13:46   ` Catalin Marinas
2024-02-27 13:53   ` Helge Deller
2024-02-26 16:14 ` [PATCH 3/4] arch: define CONFIG_PAGE_SIZE_*KB on all architectures Arnd Bergmann
2024-02-27  0:49   ` Guo Ren
2024-02-27  7:41   ` Heiko Carstens
2024-02-27  8:54   ` Geert Uytterhoeven
2024-02-27 10:59     ` Arnd Bergmann
2024-02-27 11:12       ` Geert Uytterhoeven
2024-02-27 14:18         ` Arnd Bergmann [this message]
2024-02-28 21:06   ` Stafford Horne
2024-03-05 10:59   ` Johannes Berg
2024-02-26 16:14 ` [PATCH 4/4] vdso: avoid including asm/page.h Arnd Bergmann
2024-02-26 18:53   ` Christophe Leroy
2024-02-27 12:57     ` Michael Ellerman
2024-02-27 13:46   ` Catalin Marinas

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=7b62e73d-d3fa-4432-807d-c2e667814b17@app.fastmail.com \
    --to=arnd@arndb.de \
    --cc=akpm@linux-foundation.org \
    --cc=andreas@gaisler.com \
    --cc=anna-maria@linutronix.de \
    --cc=arnd@kernel.org \
    --cc=bcain@quicinc.com \
    --cc=catalin.marinas@arm.com \
    --cc=chenhuacai@kernel.org \
    --cc=christophe.leroy@csgroup.eu \
    --cc=deller@gmx.de \
    --cc=geert@linux-m68k.org \
    --cc=gerg@linux-m68k.org \
    --cc=glaubitz@physik.fu-berlin.de \
    --cc=guoren@kernel.org \
    --cc=jan.kiszka@siemens.com \
    --cc=jcmvbkbc@gmail.com \
    --cc=kbingham@kernel.org \
    --cc=keescook@chromium.org \
    --cc=linux-alpha@vger.kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-csky@vger.kernel.org \
    --cc=linux-hexagon@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-m68k@lists.linux-m68k.org \
    --cc=linux-mips@vger.kernel.org \
    --cc=linux-openrisc@vger.kernel.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@armlinux.org.uk \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=loongarch@lists.linux.dev \
    --cc=luto@kernel.org \
    --cc=mattst88@gmail.com \
    --cc=monstr@monstr.eu \
    --cc=mpe@ellerman.id.au \
    --cc=palmer@dabbelt.com \
    --cc=richard@nod.at \
    --cc=sparclinux@vger.kernel.org \
    --cc=tglx@linutronix.de \
    --cc=tsbogend@alpha.franken.de \
    --cc=vgupta@kernel.org \
    --cc=vincenzo.frascino@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