Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1391422

Re: [PATCH v4 0/10] x86/xsaves: Fix XSAVES known issues

Show all headers | View raw

On Fri, Apr 29, 2016 at 1:40 PM, Dave Hansen
<dave.hansen@linux.intel.com> wrote:
> On 04/29/2016 01:25 PM, Andy Lutomirski wrote:
>> On Fri, Apr 29, 2016 at 1:07 PM, Yu-cheng Yu <yu-cheng.yu@intel.com> wrote:
>>> On Fri, Apr 29, 2016 at 01:03:43PM -0700, Dave Hansen wrote:
>>>> That's not feasible.  Think of dynamic libraries or just-in-time
>>>> compilers.  What instruction set does /usr/bin/java use, for instance? :)
>>>
>>> The java argument is true. In that case or when the bitmask is
>>> missing, we can allocate for all supported features.
>>
>> I actually want to see us moving in the direction of unconditionally
>> allocating everything on process startup.  If we can stop using CR0.TS
>> entirely, I think everything will be better.
>
> We can absolutely allocate the worst-case XSAVE buffer at task startup
> for folks that never want to see a latency spike in the life of the app
> no matter what.
>
> But I also think it would be pretty nice if 'ls' didn't pay the 2k cost
> to have AVX-512 state if it's not using AVX-512.  We also don't have to
> do this with CR0.TS.  We'd actually use a combination of out-of-line
> (not appended to task_struct) XSAVE buffers and XGETBV1 to check the
> size of our XSAVE buffer before we call XSAVE* and resize it when needed.
>
> Maybe nobody will ever care enough about 2kbytes/thread, though.

I suspect we're so far about 2k/thread that no one cares.

That being said, when I wrote this email, I wasn't thinking about
compacted form at all.  I think we should allocate a viable xstate
area of some sort on startup and use saves/xrstors/xsaveopt/whatever
without fiddling with TS and eagerly save and restore even if no
extended state whatsoever has been used.  I'm certainly okay in
principle with reallocating.

However, what do we do if we run out when memory when trying to reallocate?

-- 
Andy Lutomirski
AMA Capital Management, LLC

Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Re: [PATCH v4 0/10] x86/xsaves: Fix XSAVES known issues Dave Hansen <dave.hansen@linux.intel.com> - 2016-04-29 20:10 +0200
  Re: [PATCH v4 0/10] x86/xsaves: Fix XSAVES known issues Ingo Molnar <mingo@kernel.org> - 2016-04-29 21:50 +0200
  Re: [PATCH v4 0/10] x86/xsaves: Fix XSAVES known issues Dave Hansen <dave.hansen@linux.intel.com> - 2016-04-29 22:10 +0200
    Re: [PATCH v4 0/10] x86/xsaves: Fix XSAVES known issues Yu-cheng Yu <yu-cheng.yu@intel.com> - 2016-04-29 22:20 +0200
      Re: [PATCH v4 0/10] x86/xsaves: Fix XSAVES known issues Andy Lutomirski <luto@amacapital.net> - 2016-04-29 22:30 +0200
        Re: [PATCH v4 0/10] x86/xsaves: Fix XSAVES known issues Dave Hansen <dave.hansen@linux.intel.com> - 2016-04-29 22:50 +0200
          Re: [PATCH v4 0/10] x86/xsaves: Fix XSAVES known issues Andy Lutomirski <luto@amacapital.net> - 2016-04-29 22:50 +0200
            Re: [PATCH v4 0/10] x86/xsaves: Fix XSAVES known issues Dave Hansen <dave.hansen@linux.intel.com> - 2016-04-30 00:50 +0200
          Re: [PATCH v4 0/10] x86/xsaves: Fix XSAVES known issues Ingo Molnar <mingo@kernel.org> - 2016-04-30 10:00 +0200
            Re: [PATCH v4 0/10] x86/xsaves: Fix XSAVES known issues Dave Hansen <dave.hansen@linux.intel.com> - 2016-05-02 18:30 +0200
              Re: [PATCH v4 0/10] x86/xsaves: Fix XSAVES known issues Ingo Molnar <mingo@kernel.org> - 2016-05-02 20:40 +0200
      Re: [PATCH v4 0/10] x86/xsaves: Fix XSAVES known issues Dave Hansen <dave.hansen@linux.intel.com> - 2016-04-29 22:40 +0200
  Re: [PATCH v4 0/10] x86/xsaves: Fix XSAVES known issues Yu-cheng Yu <yu-cheng.yu@intel.com> - 2016-04-29 22:10 +0200

csiph-web