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
