Messages in this thread | | | From | "Bae, Chang Seok" <> | Subject | Re: [RFC PATCH 13/22] x86/fpu/xstate: Expand dynamic user state area on first use | Date | Tue, 3 Nov 2020 21:53:22 +0000 |
| |
On Tue, 2020-11-03 at 13:41 -0800, Dave Hansen wrote: > On 11/3/20 1:32 PM, Bae, Chang Seok wrote: > > On Wed, 2020-10-14 at 09:29 -0700, Dave Hansen wrote: > > > On 10/14/20 9:10 AM, Andy Lutomirski wrote: > > > > I was suggesting something a little bit different. We'd keep XMM, > > > > YMM, ZMM, etc state stored exactly the way we do now and, for > > > > AMX-using tasks, we would save the AMX state in an entirely > > > > separate > > > > buffer. This way the pain of having a variable xstate layout is > > > > confined just to AMX tasks. > > > > > > OK, got it. > > > > > > So, we'd either need a second set of XSAVE/XRSTORs, or "manual" > > > copying > > > of the registers out to memory. We can preserve the modified > > > optimization if we're careful about ordering, but only for *ONE* of > > > the > > > XSAVE buffers (if we use two). > > > > For what is worth, > > > > If using two buffers, the buffer for saving the tile data also needs > > space > > for the legacy states. > > Just to be clear, you're talking about the 512-byte 'struct > fxregs_state' which is the first member of 'struct xregs_state', right?
Yes.
> > > The AMX state is stored at the end of the XSAVE buffer (at least for > > now). > > So, the layout (in terms of offsets of non-AMX states) won't be changed > > at > > run-time. > > I don't know what point you are trying to make here.
I was trying to clarify the concern that Andy had:
"the pain of having a variable xstate layout"
Thanks, Chang
| |