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

* Dave Hansen wrote: > On 04/30/2016 12:53 AM, Ingo Molnar wrote: > > We can still use the compacted area handling instructions, because > > presumably > > those are the fastest and are also the most optimized ones? But I wouldn't > > use > > them to do dynamic

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

* Dave Hansen wrote: > On 04/30/2016 12:53 AM, Ingo Molnar wrote: > > We can still use the compacted area handling instructions, because > > presumably > > those are the fastest and are also the most optimized ones? But I wouldn't > > use > > them to do dynamic allocation: just allocate the

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

On 04/30/2016 12:53 AM, Ingo Molnar wrote: > We can still use the compacted area handling instructions, because presumably > those are the fastest and are also the most optimized ones? But I wouldn't > use > them to do dynamic allocation: just allocate the maximum possible FPU save > area at

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

On 04/30/2016 12:53 AM, Ingo Molnar wrote: > We can still use the compacted area handling instructions, because presumably > those are the fastest and are also the most optimized ones? But I wouldn't > use > them to do dynamic allocation: just allocate the maximum possible FPU save > area at

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

* Dave Hansen 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. [...] A C library might decide to use AVX-512 memset(). RAM is cheap, while allocation complexity, especially in

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

* Dave Hansen 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. [...] A C library might decide to use AVX-512 memset(). RAM is cheap, while allocation complexity, especially in the kernel, has various other

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

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

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

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

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

On Fri, Apr 29, 2016 at 1:40 PM, Dave Hansen wrote: > On 04/29/2016 01:25 PM, Andy Lutomirski wrote: >> On Fri, Apr 29, 2016 at 1:07 PM, Yu-cheng Yu wrote: >>> On Fri, Apr 29, 2016 at 01:03:43PM -0700, Dave Hansen wrote: That's not

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

On Fri, Apr 29, 2016 at 1:40 PM, Dave Hansen wrote: > On 04/29/2016 01:25 PM, Andy Lutomirski wrote: >> On Fri, Apr 29, 2016 at 1:07 PM, Yu-cheng Yu 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

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

On 04/29/2016 01:25 PM, Andy Lutomirski wrote: > On Fri, Apr 29, 2016 at 1:07 PM, Yu-cheng Yu 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

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

On 04/29/2016 01:25 PM, Andy Lutomirski wrote: > On Fri, Apr 29, 2016 at 1:07 PM, Yu-cheng Yu 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,

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

On 04/29/2016 01:07 PM, Yu-cheng Yu 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

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

On 04/29/2016 01:07 PM, Yu-cheng Yu 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

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

On Fri, Apr 29, 2016 at 1:07 PM, Yu-cheng Yu 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

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

On Fri, Apr 29, 2016 at 1:07 PM, Yu-cheng Yu 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

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

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

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

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

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

On 04/29/2016 12:57 PM, Yu-cheng Yu wrote: > On Fri, Apr 29, 2016 at 11:09:23AM -0700, Dave Hansen wrote: >> Once we *HAVE* XSAVES support, it also opens up the possibilities for >> doing things like dynamic XSAVE buffer allocation. For instance, let >> threads that are not _using_ AVX-512 not

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

On 04/29/2016 12:57 PM, Yu-cheng Yu wrote: > On Fri, Apr 29, 2016 at 11:09:23AM -0700, Dave Hansen wrote: >> Once we *HAVE* XSAVES support, it also opens up the possibilities for >> doing things like dynamic XSAVE buffer allocation. For instance, let >> threads that are not _using_ AVX-512 not

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

On Fri, Apr 29, 2016 at 11:09:23AM -0700, Dave Hansen wrote: > Once we *HAVE* XSAVES support, it also opens up the possibilities for > doing things like dynamic XSAVE buffer allocation. For instance, let > threads that are not _using_ AVX-512 not waste the 2k of space for it. If we can somehow

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

On Fri, Apr 29, 2016 at 11:09:23AM -0700, Dave Hansen wrote: > Once we *HAVE* XSAVES support, it also opens up the possibilities for > doing things like dynamic XSAVE buffer allocation. For instance, let > threads that are not _using_ AVX-512 not waste the 2k of space for it. If we can somehow

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

* Dave Hansen wrote: > Hi Folks, > > I've heard through the grapevine that there's some concern that we > should not be bothering to enable XSAVES because there's not a > sufficient use case for it. [...] So I have no fundamental objections against this series - I

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

* Dave Hansen wrote: > Hi Folks, > > I've heard through the grapevine that there's some concern that we > should not be bothering to enable XSAVES because there's not a > sufficient use case for it. [...] So I have no fundamental objections against this series - I didn't apply it back in

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

Hi Folks, I've heard through the grapevine that there's some concern that we should not be bothering to enable XSAVES because there's not a sufficient use case for it. Maybe it's meager today, but I still think we should do it. I'll try to lay out why. Today, on every Skylake system, this

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

Hi Folks, I've heard through the grapevine that there's some concern that we should not be bothering to enable XSAVES because there's not a sufficient use case for it. Maybe it's meager today, but I still think we should do it. I'll try to lay out why. Today, on every Skylake system, this

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

XSAVES is a kernel-mode instruction. It offers a compacted format and memory-write optimization. These patches fix known issues in the first implementation. They are intended for discussion and getting feedback before actually getting applied. Version 4 adds a new patch (#9) to fix missing XSAVE

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

XSAVES is a kernel-mode instruction. It offers a compacted format and memory-write optimization. These patches fix known issues in the first implementation. They are intended for discussion and getting feedback before actually getting applied. Version 4 adds a new patch (#9) to fix missing XSAVE