[v3,12/29] mips: Add <bits/pagesize.h>

Message ID e8cd2a53433fd235d4a3e141053928edaf782688.1727624528.git.fweimer@redhat.com
State Under Review
Delegated to: Adhemerval Zanella Netto
Headers
Series Teach glibc about possible page sizes and handle gaps in ld.so |

Checks

Context Check Description
redhat-pt-bot/TryBot-apply_patch success Patch applied to master at the time it was sent
linaro-tcwg-bot/tcwg_glibc_build--master-aarch64 success Build passed
linaro-tcwg-bot/tcwg_glibc_check--master-aarch64 success Test passed
linaro-tcwg-bot/tcwg_glibc_build--master-arm success Build passed
linaro-tcwg-bot/tcwg_glibc_check--master-arm success Test passed

Commit Message

Florian Weimer Sept. 29, 2024, 4:20 p.m. UTC
  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.
---
 sysdeps/mips/bits/pagesize.h | 2 ++
 1 file changed, 2 insertions(+)
 create mode 100644 sysdeps/mips/bits/pagesize.h
  

Comments

Maciej W. Rozycki Sept. 29, 2024, 9:07 p.m. UTC | #1
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
  
Florian Weimer Sept. 30, 2024, 9:15 a.m. UTC | #2
* 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
  
Maciej W. Rozycki Sept. 30, 2024, 10:56 a.m. UTC | #3
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
  
Florian Weimer Sept. 30, 2024, 11:43 a.m. UTC | #4
* 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
  

Patch

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