Re: i386 lazy pmap switching in trap.c

[David Laight <david%l8s.co.uk@localhost>]

On Sat, Feb 09, 2008 at 11:24:34PM +0900, YAMAMOTO Takashi wrote:
> 
> right.  i expected that someone who enables in-kernel preemption takes
> care of it. :)  it's easy:
> 
>       if (want resched) {
>               preempt();
>               pmap_load_if_necessary();
>       }
> 
> > It might be better to be able to mark the lwp as needing its pmap activated.
> > Then copying/out would lock the pmap active at the top, and release it
> > at the bottom. Context switch would load the pmap if the flag was set.
> > (ie you force the non-lazy loading of %cr3)
> 
> why do you think it's better?
> 
> the motivation of onfault_handler() was the opposite; it was to optimize
> copyin/out by eliminating the "mark the lwp", which is only necessary for
> rare cases like preemption/faults in the middle of operations.

Well, since copyin/out need a check to detect whether the pmap needs
to be loaded, the same check could 'lock' the pmap active for that lwp.
None of these checks would need any locking.

I was also thinking that in-kernel pre-emption would happen at any
place where it isn't forbidden. So it would look just like (almost)
any other context switch, which means you would be doing
'pmap_load_if_necessary()' in the normal lwp resume path - that path
doesn't want to be scanning a list of addresses...

The pcb_onfault path is hardly ever executed, AFAICT the lookup is only
done in order to decide whether to return EFAULT or to panic.
ie it isn't done in the paths that page in user memory.

        David

-- 
David Laight: david%l8s.co.uk@localhost