Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1391513
| From | Dave Hansen <dave.hansen@linux.intel.com> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: [PATCH v4 0/10] x86/xsaves: Fix XSAVES known issues |
| Date | 2016-04-30 00:50 +0200 |
| Message-ID | <rtpou-5CD-21@gated-at.bofh.it> (permalink) |
| References | (3 earlier) <rtmTE-3yl-11@gated-at.bofh.it> <rtn3k-3Ce-15@gated-at.bofh.it> <rtncZ-3HL-1@gated-at.bofh.it> <rtnwn-3Q2-25@gated-at.bofh.it> <rtnwn-3Q2-27@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
On 04/29/2016 01:49 PM, Andy Lutomirski wrote: >> > >> > 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. > ... > However, what do we do if we run out when memory when trying to reallocate? The thread has to die a horrible death. We can switch away from it, but can never switch back to it. Well we can switch to it, we just can't return to userspace. Actually, though... On my laptop 1/3 of the task_struct is XSAVE state (it's ~3k). With AVX-512, ~3/5 of it will be XSAVE, and it will be ~5k (>1 page). Breaking it in to two pieces makes it overall less likely that we'd have to fail an allocation. We'd be in a situation where we probably can't fork *anyway* if that happened.
Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll 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