[v3,12/29] mips: Add <bits/pagesize.h>
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
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
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
new file mode 100644
@@ -0,0 +1,2 @@
+#define __GLIBC_PAGE_SHIFT_MIN 12
+#define __GLIBC_PAGE_SHIFT_MAX 16