[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: pmap_remove_all() for x86
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:
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
It occured to me that remote invalidations can also be deferred. Updated
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.
Main Index |
Thread Index |