Re: [PATCH v3 1/2] x86/fpu: track AVX-512 usage of tasks

2018-11-20 Thread Samuel Neves
On Tue, Nov 20, 2018 at 1:32 PM Li, Aubrey wrote: > Thanks for your program, Samuel, it's very helpful. But I saw a different > output on my side, May I have your glibc version? > This system is running glibc 2.27, and kernel 4.18.7. The Xeon Gold 5120 also happens to be one of the Skylake-SP

Re: [PATCH v3 1/2] x86/fpu: track AVX-512 usage of tasks

2018-11-20 Thread Samuel Neves
On Tue, Nov 20, 2018 at 1:32 PM Li, Aubrey wrote: > Thanks for your program, Samuel, it's very helpful. But I saw a different > output on my side, May I have your glibc version? > This system is running glibc 2.27, and kernel 4.18.7. The Xeon Gold 5120 also happens to be one of the Skylake-SP

Re: [PATCH v3 1/2] x86/fpu: track AVX-512 usage of tasks

2018-11-18 Thread Samuel Neves
On 11/17/18 12:36 AM, Li, Aubrey wrote: > On 2018/11/17 7:10, Dave Hansen wrote: >> Just to be clear: there are 3 AVX-512 XSAVE states: >> >> XFEATURE_OPMASK, >> XFEATURE_ZMM_Hi256, >> XFEATURE_Hi16_ZMM, >> >> I honestly don't know what XFEATURE_OPMASK does. It does not

Re: [PATCH v3 1/2] x86/fpu: track AVX-512 usage of tasks

2018-11-18 Thread Samuel Neves
On 11/17/18 12:36 AM, Li, Aubrey wrote: > On 2018/11/17 7:10, Dave Hansen wrote: >> Just to be clear: there are 3 AVX-512 XSAVE states: >> >> XFEATURE_OPMASK, >> XFEATURE_ZMM_Hi256, >> XFEATURE_Hi16_ZMM, >> >> I honestly don't know what XFEATURE_OPMASK does. It does not

Re: [PATCH] x86: entry: flush the cache if syscall error

2018-10-12 Thread Samuel Neves
On Fri, Oct 12, 2018 at 2:26 PM Jann Horn wrote: > > On Fri, Oct 12, 2018 at 11:41 AM Samuel Neves wrote: > > > > On Thu, Oct 11, 2018 at 8:25 PM Andy Lutomirski wrote: > > > What exactly is this trying to protect against? And how many cycles > > >

Re: [PATCH] x86: entry: flush the cache if syscall error

2018-10-12 Thread Samuel Neves
On Fri, Oct 12, 2018 at 2:26 PM Jann Horn wrote: > > On Fri, Oct 12, 2018 at 11:41 AM Samuel Neves wrote: > > > > On Thu, Oct 11, 2018 at 8:25 PM Andy Lutomirski wrote: > > > What exactly is this trying to protect against? And how many cycles > > >

Re: [PATCH] x86: entry: flush the cache if syscall error

2018-10-12 Thread Samuel Neves
On Thu, Oct 11, 2018 at 8:25 PM Andy Lutomirski wrote: > What exactly is this trying to protect against? And how many cycles > should we expect L1D_FLUSH to take? As far as I could measure, I got 1660 cycles per wrmsr 0x10b, 0x1 on a Skylake chip, and 1220 cycles on a Skylake-SP.

Re: [PATCH] x86: entry: flush the cache if syscall error

2018-10-12 Thread Samuel Neves
On Thu, Oct 11, 2018 at 8:25 PM Andy Lutomirski wrote: > What exactly is this trying to protect against? And how many cycles > should we expect L1D_FLUSH to take? As far as I could measure, I got 1660 cycles per wrmsr 0x10b, 0x1 on a Skylake chip, and 1220 cycles on a Skylake-SP.

[tip:x86/urgent] x86/vdso: Fix lsl operand order

2018-09-01 Thread tip-bot for Samuel Neves
Commit-ID: e78e5a91456fcecaa2efbb3706572fe043766f4d Gitweb: https://git.kernel.org/tip/e78e5a91456fcecaa2efbb3706572fe043766f4d Author: Samuel Neves AuthorDate: Sat, 1 Sep 2018 21:14:52 +0100 Committer: Thomas Gleixner CommitDate: Sat, 1 Sep 2018 23:01:56 +0200 x86/vdso: Fix lsl

[tip:x86/urgent] x86/vdso: Fix lsl operand order

2018-09-01 Thread tip-bot for Samuel Neves
Commit-ID: e78e5a91456fcecaa2efbb3706572fe043766f4d Gitweb: https://git.kernel.org/tip/e78e5a91456fcecaa2efbb3706572fe043766f4d Author: Samuel Neves AuthorDate: Sat, 1 Sep 2018 21:14:52 +0100 Committer: Thomas Gleixner CommitDate: Sat, 1 Sep 2018 23:01:56 +0200 x86/vdso: Fix lsl

[PATCH] x86/vdso: fix lsl operand order

2018-09-01 Thread Samuel Neves
In the __getcpu function, lsl was using the wrong target and destination registers. Luckily, the compiler tends to choose %eax for both variables, so it has been working so far. Cc: x...@kernel.org Cc: sta...@vger.kernel.org Signed-off-by: Samuel Neves --- arch/x86/include/asm/vgtod.h | 2 +- 1

[PATCH] x86/vdso: fix lsl operand order

2018-09-01 Thread Samuel Neves
In the __getcpu function, lsl was using the wrong target and destination registers. Luckily, the compiler tends to choose %eax for both variables, so it has been working so far. Cc: x...@kernel.org Cc: sta...@vger.kernel.org Signed-off-by: Samuel Neves --- arch/x86/include/asm/vgtod.h | 2 +- 1

[tip:x86/urgent] x86/topology: Update the 'cpu cores' field in /proc/cpuinfo correctly across CPU hotplug operations

2018-02-23 Thread tip-bot for Samuel Neves
Commit-ID: 4596749339e06dc7a424fc08a15eded850ed78b7 Gitweb: https://git.kernel.org/tip/4596749339e06dc7a424fc08a15eded850ed78b7 Author: Samuel Neves <sne...@dei.uc.pt> AuthorDate: Wed, 21 Feb 2018 20:50:36 + Committer: Ingo Molnar <mi...@kernel.org> CommitDate: Fri, 23 Fe

[tip:x86/urgent] x86/topology: Update the 'cpu cores' field in /proc/cpuinfo correctly across CPU hotplug operations

2018-02-23 Thread tip-bot for Samuel Neves
Commit-ID: 4596749339e06dc7a424fc08a15eded850ed78b7 Gitweb: https://git.kernel.org/tip/4596749339e06dc7a424fc08a15eded850ed78b7 Author: Samuel Neves AuthorDate: Wed, 21 Feb 2018 20:50:36 + Committer: Ingo Molnar CommitDate: Fri, 23 Feb 2018 08:47:47 +0100 x86/topology: Update

[PATCH] smpboot: correctly update number of booted cores

2018-02-21 Thread Samuel Neves
: 3 cpu cores : 2 cpu cores : 2 This patch fixes this by always zeroing the booted_cores variable upon turning off a logical CPU. Signed-off-by: Samuel Neves <sne...@dei.uc.pt> --- arch/x86/kernel/smpboot.c | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/x86/kernel/smp

[PATCH] smpboot: correctly update number of booted cores

2018-02-21 Thread Samuel Neves
: 3 cpu cores : 2 cpu cores : 2 This patch fixes this by always zeroing the booted_cores variable upon turning off a logical CPU. Signed-off-by: Samuel Neves --- arch/x86/kernel/smpboot.c | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/x86/kernel/smpboot.c b/arch/x86/kernel