Re: i386 lazy pmap switching in trap.c

[yamt%mwd.biglobe.ne.jp@localhost (YAMAMOTO Takashi)]

> On Sat, Feb 09, 2008 at 09:32:44PM +0900, YAMAMOTO Takashi wrote:
> > > On Fri, Feb 08, 2008 at 09:14:44PM +0000, David Laight wrote:
> > > > On Fri, Feb 08, 2008 at 08:00:17PM +0000, David Laight wrote:
> > > > > Am I missing something?
> > > > 
> > > > Yes ... we need that pmap_load() because we've (probably) slept in
> > > > uvm_fault().
> > > 
> > > Related though, why the retry loop in DO_DEFERRED_SWITCH_RETRY ?
> > > 
> > >   David
> > > 
> > > -- 
> > > David Laight: david%l8s.co.uk@localhost
> > 
> > the intention of the loop was to be friendly with future in-kernel 
> > preemption.
> > onfault_handler() can't detect if the lwp is preempted during pmap_load().
> 
> Ah - except that isn't going to work - since the pre-emption can happen
> during the copyout itself.
> Unless you make every pre-emption check the onfault_handler() address list.

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.

YAMAMOTO Takashi

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