On Sat, Feb 05, 2000 at 11:00:49PM +0100, Manfred Spraul wrote:
> * Alpha doesn't use mm->cpu_vm_mask.
No, but there's no reason we couldn't.
> * the tlb could contain entries from multiple processes,
> selected by the ASN.
Yes.
> * the actual page table pointer is changed during switch_to(), not
> during switch_mm(). Is that an atomic operation, or could IPI's arrive
> between the page table pointer/ASN change and the "current" change?
Yes, it's atomic. It's the reason we still have activate_mm,
because we couldn't separate the two operations.
> But I don't understand what happens in the following scenario:
>
> CPU0: CPU1:
> thread mmA page stealer(kswapd)
>
> thread switch to mmB
>
> changes a page from mmA
> flush_tlb_page(mmA,...)
> IPI!
> * notices that mmA is not loaded, no flush
> * mmA stored in .delayed_flush
>
> thread switch back to mmA
> * prepare_to_switch() clears .delayed_flush
>
> switch_mm(): ASN not yet wrapped, tlb reactivated.
> !! data access without tlb flush!!
This doesn't happen because CPU1 did flush_tlb_other, either
by noticing that mmA wasn't running on cpu1, or by noticing
that mmA had more than one user.
But this leads to a different failing scenario:
CPU0: CPU1:
switch_mm(A,mmA)
this implies A->thread.asn
and mmA->context are valid.
flush_tlb_other(A)
this implies mmA->context is 0.
switch_to(A)
Now A->thread.asn is out of
sync with mmA->context.
This will require some thought to avoid scrogging schedule entirely.
r~
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Mon Feb 07 2000 - 21:00:12 EST