On Tue, Feb 27, 2024, at 12:12, Geert Uytterhoeven wrote: > On Tue, Feb 27, 2024 at 11:59 AM Arnd Bergmann <a...@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 _______________________________________________ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc