In article <16963.6358.943374.42639@basis.lke.rad.klinikum.rwth-aachen.de>
kilbi@rad.rwth-aachen.de wrote:

> I've tested your new patch w/ and w/o chuq's separate "pmap_unwire:
> wiring ..." patch on my qube2 (256MB RAM, 160 GB IDE harddisk):

Thank you for your testing :-)

> - Your new patch seems to perform a bit better than your old one:
>   System perforamnce is now the same as with a stock kernel. The old
>   patch decreases system performance about 10%.
 :
>   Concering data corruption: Your old patch seems to be more reliable
>   than your new one. The more processes run in parallel the more
>   likely the data corruptions appear.

Hmm. The old one have two more changes:

- In pmap.c:pmap_enter(), call pmap_remove(9) before pmap_pv_enter()
  in case of mapping changes.
- In vm_machdep.c:vmapbuf(), add VM_PROT_READ|VM_PROT_WRITE to
  pmap_enter(9) flags. (as noted by chuq, it should be fixed properly)

These change might cause more cache flushes, so it could be
slower but less data corruption, I think.

>   Concerning the frozen system: I'm not able to enter ddb, no reaction
>   to serial break signal (while 'ddb.fromconsole = 1').

Does the freeze also happen *without* my patch or not?
If my patch causes the freeze, I have to rethink what is wrong.

> So, it's much much better, but (as expected?) not perfect.

Yes, the patch doesn't handle all possible virtual aliases.
It's just a workaround, but I'll commit it as an interim fix.

> First thanks for your effort, and anything else I can test?

If you have some R4000/R4400 with L2 machines, I'd like to see
how your test script works on such machines.
---
Izumi Tsutsui