From: "Maciej W. Rozycki" <macro@codesourcery.com>
To: Andrew Pinski <pinskia@gmail.com>
Cc: Andrew Stubbs <ams@codesourcery.com>,
"libc-ports@sourceware.org" <libc-ports@sourceware.org>
Subject: Re: [PATCH] PAGE_SIZE definition for MIPS XLP
Date: Wed, 20 Nov 2013 19:57:00 -0000 [thread overview]
Message-ID: <alpine.DEB.1.10.1311192019520.21686@tp.orcam.me.uk> (raw)
In-Reply-To: <CA+=Sn1nSOoXDFzmCbBEREJiQCxg_GoPXf6QNBS5UFRmQMVng8A@mail.gmail.com>
On Tue, 19 Nov 2013, Andrew Pinski wrote:
> > MIPS' sys/user.h currently has a constant definition for PAGE_SIZE, and the
> > other related settings. This is not appropriate for XLP (and other MIPS?)
> > where the actual page size is a kernel configuration option.
>
> The whole Octeon series of MIPS64 processors also supports other
> PAGE_SIZEs. Also the generic MIPS glibc should support other page
> sizes too.
Virtually all MIPS processors that have a TLB MMU, except a few old
oddballs, support a configurable page size (on a page-by-page basis, but
Linux sets the size globally). The exceptions are the R2000/R3000 MIPS I
ISA CPUs and their variations (fixed 4kB page size) and the R6000 MIPS II
ISA CPU (fixed 16kB page size). The latter hardly ever seen anywhere
(being a costly ECL discrete CPU chip set) and never supported by Linux.
Therefore there's no point ever in hardcoding any particular page size for
the MIPS port.
Of the sizes offered by standard hardware, ranging from 1kB up to 256TB
at the every other power of 2, Linux chose to support 4kB, 16kB and 64kB
pages.
> > Apart from the general principle of not having incorrect definitions, the
> > actual problem that needs to be solved is in
> > sysdeps/unix/sysv/linux/ifaddrs.c in which PAGE_SIZE is used by preference
> > as an optimization. Most of the other possible use cases prefer to call
> > __getpagesize or use sysconf, and so are unaffected.
The case of ifaddrs.c seems ill-conceived to me. If such a kind of
optimisation is desired, then I think on targets that have a fixed page
size getpagesize should simply be implemented as a static inline function
so that GCC can reduce any calls to an instantiation of the constant
returned.
Maciej
prev parent reply other threads:[~2013-11-19 20:56 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-11-18 12:51 Andrew Stubbs
2013-11-18 13:42 ` Andreas Schwab
2013-11-19 20:56 ` Maciej W. Rozycki
2013-11-18 13:45 ` Joseph S. Myers
2013-11-18 18:21 ` Joseph S. Myers
2013-11-19 3:28 ` Andrew Pinski
2013-11-19 14:57 ` Joseph S. Myers
2013-11-19 20:19 ` Andrew Stubbs
2013-11-20 19:57 ` Maciej W. Rozycki [this message]
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=alpine.DEB.1.10.1311192019520.21686@tp.orcam.me.uk \
--to=macro@codesourcery.com \
--cc=ams@codesourcery.com \
--cc=libc-ports@sourceware.org \
--cc=pinskia@gmail.com \
/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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).