Re: AVX support

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

Out of curiosity, on sparc64 is the structure/storage for FPU (and other “optional”) context dynamically allocated only for binaries which use the co-processor instructions (however that’s marked or determined) or for every process without regard to co-processor use? How would we want that to work on x86?

	Erik


> On Aug 15, 2016, at 08:23, Maxime Villard <max%m00nbsd.net@localhost> wrote:
> 
> Le 15/08/2016 à 15:46, Martin Husemann a écrit :
>> On Mon, Aug 15, 2016 at 09:57:05AM +0200, Maxime Villard wrote:
>>> One huge problem that struck me was that the fpu state is placed in the
>>> kernel
>>> stack, which means we lose ~2500 bytes of stack. With the latest MPX states
>>> and
>>> the future extensions, we will lose even more memory. The priority is
>>> moving the
>>> fpu out of the pcb. We could give a look at FreeBSD [3], since their pcb
>>> only
>>> has a pointer to a dynamically-allocated area.
>> 
>> No need to look at FreeBSD for that ;-)
>> 
>> When I last measured that for sparc64, where we have only a pointer in the
>> pcb, I never saw any process exit that did NOT allocate the fpu state.
>> 
>> This was some years ago, and maybe my instrumentation was bogus.
>> 
>> If this is still the case, it might make more sense to just add another
>> page to the uarea instead and save the pool_cache_get() overhead.
>> 
> 
> I don't think an additional page is a nice idea. One day or another, we will
> have to move it anyway.
> 
> By the way, I've investigated the FreeBSD code, and in fact the fpu pointer in
> the pcb points to the end of the pcb, and is not dynamically-allocated. So they
> have the same problem as us.
> 
> I've given a look at sparc64, and indeed the fpu is stored as a pointer in
> struct mdlwp, which is separate from the pcb. The pointer is dynamically-
> allocated via the fpstate_cache pool cache. I think this is a nice design, we
> should implement the same on x86.