Re: AVX support

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

On Wed, Jan 01, 2014 at 07:45:24PM +0000, Alexander Nasonov wrote:
> David Laight wrote:
> > Slowly ...
> > Unfortunately it isn't as simple as one might expect.
> > Random differences between the amd64 and i386 code don't help matters.
> > (You are in a maze of structures that define the same physical data.)
> 
> I'm sure it's quite complicated. 

Bits seem to have been bolted on by people who are scared to change
the old code.
I suspect a lot of the amd64 stuff was done when it wasn't a 'real'
system and no one thought it would be important!
So it was a big load of cut/paste/edit of the i386 code rather than
the common parts being kept common.
Given that amd64 has to run 32bit binaries a lot of the code should
be more common.

> > Amongst other problems there are a few places where a full copy of the
> > FP (etc) state structure ends up on the stack (and IIRC in some code
> > paths several of them). Increasing the size from 512 bytes (quite large
> > for the kernel stack) to a potentially very large value - nearly 1024
> > just for AVX - might cause stack overflow problems.
> > Not helped by the actual FP save area being in the stack pages.
> 
> Is it the case for all arches or only if there is no pcu(9) support? In
> the latter case, would switching to pcu(9) interface help to combat this
> problem?

Someone tried changing the FP register save to use pcu - and broke
everything (as well as slowing it down a lot).
 
> > One of the really bad code paths is the core dump code.
> 
> Are you talking about userspace cores and gdb code? This sounds
> like a work for a phase II.

Unfortunately it is all rather tied together.
Although getting core dumps to work properly could be 'phase II'
not thinking about them early on just makes things too hard.

> At this point, I'm just playing with AVX instruction and I can
> happily use (and test) any half-baked patch if you have one.

I haven't got that far yet.
I am looking at it at the moment, but don't expect anything soon.
I've sort of remembered why I decided it was all too hard last xmas!

I've an i7 here that supports AVX (but not AVX2), and might squeeze a
test on a system at work that does support AVX2.
Also a couple of older systems (including a pseudo 486).

        David

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