On Tue, Aug 26, 2014 at 11:42:30AM +0100, Maciej W. Rozycki wrote: > > > I cannot reproduce it on demand, so I'm not really sure what the cause could > > > be. PAGE_SIZE should be largely transparent to userland these days, so I am > > > wondering if this might be more oddities w/ an R14000 CPU. > > > > This sound very unlikely as the CPU was primarily designed to run IRIX and > > SGI's systems were using 16k or even 64k page size. > > > > What userland are you running and how old is it? Are you seeing different > > results for 16k and 64k? > > FWIW, I've been always using the 16k page size exclusively with my 64-bit > userland and my SWARM board using the SB-1/BCM1250 processor (with either > endianness) and never had issues even with stuff as intensive as native > GCC bootstrapping (with all the languages enabled such as Ada and Java) or > glibc builds. It's been like 8 years now and quite recent kernels like > from two months ago gave me no trouble either. So it must be something > specific to the configuration, my first candidates to look at would be the > generated TLB and cache handlers, that are system-specific. Generally the R10000 architecture is such that there is much less potencial for software bugs as well. The TLB is nice, cleans up conflicting entries so no TLB shutdown or similar horrors possible. And the caches while they suffer from cache aliases, will cleanup those aliases transparently to software, that is an OS can treat them as non-aliasing. R10000 systems with the notable exception of the SGI O2 and Indigo² R10000 have fully coherent I/O. Basically the only thing that needs to be done in software is I-cache coherency. The I-cache snoops stores by remote CPUs but not by the local CPU itself so in a sense SMP is a simpler case than UP even. Ralf
