this problem occurs in kernel space (kseg0), not user space. In user space
there is no problem due to the TLB "protection" of PREFs going outside the
process working set, but that doesn't help in kernel mode.
Dominic Sweetman writes:
> Carsten Langgaard (firstname.lastname@example.org) writes:
> > I think we have a problem with the PREF instructions spread out in the
> > memcpy function.
> Not really. The MIPS32 manual (for example):
> "PREF does not cause addressing-related exceptions. If it does happen
> to raise an exception condition, the exception condition is
> ignored. If an addressing-related exception condition is raised and
> ignored, no data movement occurs."
> PREF never generates a memory operation for a location with an
> uncached memory access type."
> For a Linux user program, at least, memory pages are "memory-like":
> reads are guaranteed to be side-effect free, so any outlying
> prefetches are harmless. It's hard to see any circumstance where an
> accessible cacheable location would lead to bad side-effects on read.
> Dominic Sweetman,
> MIPS Technologies (UK) - formerly Algorithmics
> The Fruit Farm, Ely Road, Chittering, CAMBS CB5 9PH, ENGLAND
> phone: +44 1223 706200 / fax: +44 1223 706250 / direct: +44 1223 706205