| Message ID | e8cd2a53433fd235d4a3e141053928edaf782688.1727624528.git.fweimer@redhat.com |
|---|---|
| State | New |
| Headers | show |
| Series | Teach glibc about possible page sizes and handle gaps in ld.so | expand |
On Sun, 29 Sep 2024, Florian Weimer wrote: > According to arch/mips/Kconfig in the Linux sources, MIPS supports > 4 KiB, 8 KiB, 16 KiB, 32 KiB, 64 KiB page sizes depending on > CPU/configuration. OK as far as the MIPS/Linux port is concerned only. Of these 4 KiB, 16 KiB, 64 KiB are standard MIPS architecture page sizes (three of many), and 8 KiB, 32 KiB are a Cavium Octeon vendor extension (I don't know offhand if there any other non-standard sizes supported by that hardware). > --- > sysdeps/mips/bits/pagesize.h | 2 ++ > 1 file changed, 2 insertions(+) > create mode 100644 sysdeps/mips/bits/pagesize.h NB other page sizes are architecturally supported by TLB MMU hardware, from 1 KiB up to 256 TiB, but not by the MIPS port of Linux, so shouldn't this be sysdeps/unix/sysv/linux/mips/bits/pagesize.h instead, so as not to apply the limitations of MIPS/Linux to the generic MIPS architecture? Or should this: > diff --git a/sysdeps/mips/bits/pagesize.h b/sysdeps/mips/bits/pagesize.h > new file mode 100644 > index 0000000000..cd688d3fb0 > --- /dev/null > +++ b/sysdeps/mips/bits/pagesize.h > @@ -0,0 +1,2 @@ > +#define __GLIBC_PAGE_SHIFT_MIN 12 > +#define __GLIBC_PAGE_SHIFT_MAX 16 be: #define __GLIBC_PAGE_SHIFT_MIN 10 #define __GLIBC_PAGE_SHIFT_MAX 48 instead? It's not clear to me from the cover letter: "[...] To avoid the overhead and loss of test coverage by accepting gaps everywhere, this series teaches glibc the possible range of page sizes for each supported architecture." (or indeed BZ referred) which of the alternatives I quote above is right, i.e. I find "supported architecture" ambiguous here -- is it an OS port or a CPU architecture? Please clarify. Maciej
* Maciej W. Rozycki: > On Sun, 29 Sep 2024, Florian Weimer wrote: > >> According to arch/mips/Kconfig in the Linux sources, MIPS supports >> 4 KiB, 8 KiB, 16 KiB, 32 KiB, 64 KiB page sizes depending on >> CPU/configuration. > > OK as far as the MIPS/Linux port is concerned only. > > Of these 4 KiB, 16 KiB, 64 KiB are standard MIPS architecture page sizes > (three of many), and 8 KiB, 32 KiB are a Cavium Octeon vendor extension (I > don't know offhand if there any other non-standard sizes supported by that > hardware). Thank you for this information. >> sysdeps/mips/bits/pagesize.h | 2 ++ >> 1 file changed, 2 insertions(+) >> create mode 100644 sysdeps/mips/bits/pagesize.h > > NB other page sizes are architecturally supported by TLB MMU hardware, > from 1 KiB up to 256 TiB, but not by the MIPS port of Linux, so shouldn't > this be sysdeps/unix/sysv/linux/mips/bits/pagesize.h instead, so as not to > apply the limitations of MIPS/Linux to the generic MIPS architecture? In theory, any architecture could have future CPUs that support larger page sizes, so there is no absolute strict upper limit. For <sys/pagesize.h> to be useful to programmers, the maximum needs to reflect what they can reasonably expect to matter during the life time of the file format and application. A good indicator of future directions for page size is what binutils ld generates by default. On Linux, the page size cannot really be larger than what ld bakes into the binaries. > "[...] To avoid the overhead and loss of test coverage by accepting > gaps everywhere, this series teaches glibc the possible range of page > sizes for each supported architecture." > > (or indeed BZ referred) which of the alternatives I quote above is right, > i.e. I find "supported architecture" ambiguous here -- is it an OS port or > a CPU architecture? It's the combination of both. Thanks, Florian
On Mon, 30 Sep 2024, Florian Weimer wrote: > > "[...] To avoid the overhead and loss of test coverage by accepting > > gaps everywhere, this series teaches glibc the possible range of page > > sizes for each supported architecture." > > > > (or indeed BZ referred) which of the alternatives I quote above is right, > > i.e. I find "supported architecture" ambiguous here -- is it an OS port or > > a CPU architecture? > > It's the combination of both. So I guess it should go into sysdeps/unix/sysv/linux/mips/bits/pagesize.h then, shouldn't it? Then it'll fail compilation if someone tries to build glibc for a non-Linux MIPS platform, bringing their attention to the need to add these bits to their port rather than silently using Linux settings and possibly causing tough to track down troubles later on. Am I missing anything here? Maciej
* Maciej W. Rozycki: > On Mon, 30 Sep 2024, Florian Weimer wrote: > >> > "[...] To avoid the overhead and loss of test coverage by accepting >> > gaps everywhere, this series teaches glibc the possible range of page >> > sizes for each supported architecture." >> > >> > (or indeed BZ referred) which of the alternatives I quote above is right, >> > i.e. I find "supported architecture" ambiguous here -- is it an OS port or >> > a CPU architecture? >> >> It's the combination of both. > > So I guess it should go into sysdeps/unix/sysv/linux/mips/bits/pagesize.h > then, shouldn't it? Then it'll fail compilation if someone tries to build > glibc for a non-Linux MIPS platform, bringing their attention to the need > to add these bits to their port rather than silently using Linux settings > and possibly causing tough to track down troubles later on. Am I missing > anything here? I think this makes sense for MIPS. Are there any other glibc targets with a software-defined TLB and where page sizes are similarly kernel-defined? Thanks, Florian
diff --git a/sysdeps/mips/bits/pagesize.h b/sysdeps/mips/bits/pagesize.h new file mode 100644 index 0000000000..cd688d3fb0 --- /dev/null +++ b/sysdeps/mips/bits/pagesize.h @@ -0,0 +1,2 @@ +#define __GLIBC_PAGE_SHIFT_MIN 12 +#define __GLIBC_PAGE_SHIFT_MAX 16