Andrew Doran wrote:
On Tue, Jun 03, 2008 at 03:01:43PM +0100, Andrew Doran wrote:On Tue, Jun 03, 2008 at 04:01:20PM +0200, Christoph Egger wrote:On Tuesday 03 June 2008 15:37:44 Andrew Doran wrote:http://www.netbsd.org/~ad/pmap.diff Is there anything wrong with this? Have I missed a case where we can avoid an invalidation?In pmap_free_ptp() I don't see where you initialize invaladdr2. To me, this looks like using an uninitialized variable.I made that change after testing it; the remove_all bit does work well though.It occured to me that remote invalidations can also be deferred. Updated diff: http://www.netbsd.org/~ad/pmap2.diff
From my scant knowledge of x86 pmap it looks ok.In pmap_tlb_shootdown, can the test be moved further up the file? Everything before it looks to only effect local variables.
I've one query, which is more due to my lack of knowledge about how -current kernel works, than the change. Is there ever a risk that an lwp might not complete the removal, eg, fast soft interrupts, which borrow the lwp on leaving an interrupt. If one of them starts a pmap_remove_all which then gets blocked (taking a lock in the UVM layer?), it hands the lwp back to where it borrowed it from, and schedules up it's own lwp, and so loses the pmap gc state information.
Is the above ever a risk? If so then perhaps the new lwp items need to be tied to the pmap rather than curlwp.
Thanks, Chris