Re: pcb offset into uarea

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

On Sun, Feb 16, 2014 at 01:27:50PM -0800, Matt Thomas wrote:
> > An alternative would be to place the FP save area at the start of the uarea.
> > This would mean that, on stack overflow, the FP save area would be trashed
> > before some random piece of memory.
> > It might even be worth putting the pcb at the start of the uarea - so that
> > stack overflow crashes out the failing process, and probably earlier
> > than the random corruption would.
> 
> For most ports, the pcb is at the start of the uarea.

Interesting since i386 puts it at the end.

> > This gives me three options:
> > A) Put the save area at the end of the pcb and dynamically adjust the pcb
> >   offset.
> > B) Put the save area at the start of the uarea, with the pcb at a fixed
> >   offset at the end of the uarea.
> > C) Put the save area at the end of the pcb, and put the pcb at the start
> >   of the uarea.
> > 
> > Votes?
> > What have I missed?
> 
> Keep a default mmx/sse save area in the pcb along with a pointer to it.
> If a variant is used that needs a larger save area, dynamically allocate
> it and save it in the pcb pointer.
> 
> Since it's unlikely most processes will be AVX why waste the space?

Unfortunately I dont think it is possible to determine whether a
process has used the AVX instructions.
There is a bit for 'os supports avx' (ie swaps on context switch) that
causes the instructions to fault (if not set), but applications should
look at that before using avx instructions.

If a process switch happens in a system call then the avx (xmm and ymm)
registers need not be saved and restored. They can be zeroed instead
because they are all caller saved.
I'm not 100% how easy that is to detect, but it shouldn't be too hard an
optimisation to perform.

Zeroing the ymm registers also has a significant performance benefit.

        David


        David

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