Re: "Hijacking" a PCU.

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

On Sat, Dec 15, 2012 at 09:23:00AM -0800, Matt Thomas wrote:
> 
> 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.

I've tried to read the patch, and I'm not entirely sure it is a good
solution.
Not least because, I think it requires multiple 'save areas' for
each LWP.

On amd64 the safe area we currently have for SSE2 is 512 bytes.
Add support for the 256 AVX instructions and it increases to 832.
You really don't want to be allocating multiple such saved areas
(per lwp) on the off chance the kernel might want to use the registers.

What almost works is to make the current lwp the resource owner,
then require the kernel code to save and restore any registers it
modifies.
There are several problems though:
1) gdb (etc) will find the wrong registers for the lwp.
2) Partial state is hard to save (I think i387 is very nasty here).
3) Saving and restoring a register may zero the high bits of an
   extended version of that register.

An alternative would be to make the code that wants to use the
PCU provide the save area (or probably a place where a malloced
pointer to the save area will be written).

You'd then need to save the processes user-space state in the lwp
and then put a pointer the temporary save area into the lwp.
Process switches would then cause the state to be saved in the
temporary location.

When finished everything can be unwound and the PCU marked 'available'.

This all means that the you'd have to be doing a significant amount
of work with the PCU in order to make it all worthwhile.
As well as the save/restore, things like changing the mode of the PCU
can take a lot of clocks - I read 170 to switch from SSE2 to AVX).

        David

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