Subject: Re: "pmap_unwire: wiring ... didn't change!"
To: None <firstname.lastname@example.org>
From: Izumi Tsutsui <email@example.com>
Date: 03/25/2005 23:13:04
In article <firstname.lastname@example.org>
> 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.