Re: "Hijacking" a PCU.

[Matt Thomas <matt%3am-software.com@localhost>]

On Dec 15, 2012, at 9:23 AM, Matt Thomas wrote:

> One of the features added to NetBSD 6 was a machine-independent framework for 
> dealing with "Per-CPU Units" (PCU).  These are things such as FPUs or SIMDs.  
> By handing all the complex stuff (lazy switching), a lot of machine-dependent 
> code goes away.
> 
> However, there is one disadvantage to using PCU.  If you want to use a PCU in 
> the kernel (for faster copies for instance), PCU isn't very accommodating.
> 
> In the patch at http://www.netbsd.org/~matt/pcu-hijack.txt I've implemented 
> the concept of hijacking a PCU for a kernel LWP to use.  If you assume that 
> most LWPs won't be using the PCU, then using the PCU for the kernel should 
> have little overhead since it shouldn't need to save/restore PCU state since 
> there is no one else using it.  But one thing you don't want is lazy 
> switching since the LWP that the hijacked PCU will be using it until it 
> surrenders it.
> 
> To accomodate this, whenever a LWP that has hijacked a PCU is resumed and it 
> no longer owns the PCU, it saves the current PCU state and immediately 
> re-loads its own hijacked state.  When the PCU is surrendered, the PCU state 
> is simply discarded since when the PCU was initially hijacked, any state that 
> needed to saved was saved.
> 
> Using this feature, one could easily implement AltiVec or NEON based 
> copyin/copyout/etc.

I've updated the diff and now use pcu_kernel_acquire / pcu_kernel_release 
instead of pcu_hijack / pcu_surrender.

All 3 callbacks take a flags a argument which indicates whether the
operation is for KERNEL or not.  Also load has USED and NOLOAD flags
as well.  NOLOAD is used to reenable the PCU unit but skips loading
the registers since they are already current in the PCU.