Re: AVX support

[Erik Fair <fair%netbsd.org@localhost>]

Has AVX support in NetBSD (context switching) been revisited yet?

According to https://en.wikipedia.org/wiki/Advanced_Vector_Extensions#Operating_system_support we’re even later than FreeBSD and OpenBSD.

	curious,

	Erik <fair%netbsd.org@localhost>



> On Jan 1, 2014, at 12:45, David Laight <david%l8s.co.uk@localhost> wrote:
> 
> 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