[prev in list] [next in list] [prev in thread] [next in thread] 

List:       linux-alpha
Subject:    Re: 2.3.42 alpha updates
From:       Richard Henderson <rth () cygnus ! com>
Date:       2000-02-05 23:37:57
[Download RAW message or body]

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~

[prev in list] [next in list] [prev in thread] [next in thread]