Re: AVX support

[Maxime Villard <max%m00nbsd.net@localhost>]

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.