Re: [patch] 2.4, head: PAGE_SHIFT changes break glibc

[Ralf Baechle <ralf@linux-mips.org>]

On Fri, Nov 21, 2003 at 06:33:37PM +0100, Maciej W. Rozycki wrote:

>  Recent changes made to <asm/page.h> break a build of glibc 2.2.5 for me.  
> Compilation bails out due to PAGE_SHIFT being undeclared -- glibc pulls it
> as it uses PAGE_SIZE in linuxthreads/internals.h.  The PAGE_SHIFT macro
> depends on configuration now (I use an empty cofinguration for glibc
> headers, hence the error) and thus it'd better be simply private to the
> kernel.  Glibc will then use sysconf(_SC_PAGE_SIZE) which now better
> reflects actual configuration of the system it's run on.

Interesting.  IA-64 does the same thing, for example.  Wonder why they
seem to be able to get away with that.  At the very least including the
kernel header file may pick up a wrong value for PAGE_SHIFT.

>  Here's a patch that limits PAGE_SIZE to the kernel scope.  If there's any
> other program that needs PAGE_SIZE, it should be converted to
> sysconf(_SC_PAGE_SIZE) as well.
> 
>  OK to apply?

Yes, please go ahead.

>  Additionally, I think we should also implement the getpagesize syscall to
> benefit statically linked programs (and make glibc use it like for other
> platforms that use variable page sizes).

The kernel is already passing AT_PAGESZ to ELF binaries.  Wouldn't that
be sufficient?  Currently it's passing the largest supported page size,
that is 64k.  However this constant is always passed even when a smaller
page size is configured.

>  Finally, I'm not sure such a
> noticeable change was a good move in these late days of 2.4...

TLB reloads have been shown to be a major performance problem; this is an
not yet completed attempt to improve the situation so people don't need
to go for crude hacks such as wired TLB entires and similar.

Other parts of improvments such as hugetlbfs are available in 2.6 only
anyway.  I'm also thinking of changing the pagetable structure back to
the aggressivly optmized thing we were using before Linux 2.0.14 - but
certainly not for 2.4 - too intrusive, as you say.  With most MIPS users
being embedded users I still expect 2.4 to live for quite a while -
certainly longer than I'd like to see ...

  Ralf