Re: Threads race for VM

vandys@cisco.com writes:

>After taking a slightly longer look at this, I've come the realization
>that
>this approach won't work. Imagine that thread1 has faulted on the
>address,
>and comes into the kernel. But then his clock ticks, and the CPU goes
>off
>to do that.

>In parallel, thread2, on another process (SMP), faults on the same
>address,
>comes in, resolves the fault, and returns.

Ah... I see. thread1 hasn't taken the pset lock yet, so he could
be pre-empted without even falling asleep on a semaphore.
Probably unlikely, but certainly possible.

>Thread1 finishes with the clock tick, and takes the lock on the slot.
>There
>is no contention, because thread2 has come and gone. And yet, not only
>is
>the page valid, but there's a mapping in their (shared) address space.

>I'm going to need to ponder whether it's better to add a
>per-virtual-page
>data structure to the pview, or whether it's acceptable to consult the
>atl
>list for a physical page at mapping time. I'm leaning towards the
>latter,
>since this is already done for the detach. But I can probably fix both
>add
>and delete cases if I convert to a pview-level per-page flag.

I'm curious: how would the per-virtual-page struct help us
here?

I'm also wondering if that scenario could be avoided by holding
off pre-emption until we have the pset lock. It's not very far
from the sti() in trap() until the find_pview() in vas_fault().
Allowing another thread in that period has the effect of
invalidating the processor's decision to enter the trap. Unless
there's a real easy way to revalidate that decision after the
slot lock is taken, I don't know if it makes sense to allow
another thread to come in at that point.

Eric
Received on Thu Nov 4 12:03:05 1999