Hi Neil,

I've had r3000s a lot longer than r4000s so I have better intuition
for physically-addressed caches.  The mips3 chips I use heavily have
physically-addressed L2s, detect aliasing and deliver an exception
when it occurs. The kernel then writes back the old aliased page,
flushes it, and lets the new user load in the new mapping.
Castor Fu or Soda-San would know more about the no-L2-cache cases.

But sounds like you're tuning for VACs which dont have adequate
hardware ASID support, so you have to flush the entire cache on
every context-switch. Is that right?

In any case, if you get a copy-on-write fault, don't you still have to
force a write-back of the source page, so that you can read it
consistently via the kernel's mapping (rather than the user-space
mapping. (See the nasty comment 

	 * If  we have a virtually-indexed, physically-tagged cache,
	 * and no L2 cache to warn of aliased mappings,  we must force an
	 * write-back of all L1 cache lines of the source physical address,

in the mips pmap.)

Can you do that per-page on the ARM for data pages, or not?
(For text pages, you're probably inserting or removing a breakpoint,
and on strongarm that means flushing the entire icache, right?)


Re kernel threads and pmap/VAC switching: gwr has written lots about
how we already optimize them.  I'd check the tech-kern archives.