Re: [LKP] [lkp] [x86/hweight] 65ea11ec6a: will-it-scale.per_process_ops 9.3% improvement

On August 25, 2016 4:45:06 AM PDT, Borislav Petkov wrote: >On Thu, Aug 25, 2016 at 03:05:19AM -0700, H. Peter Anvin wrote: >> I'm wondering if one of those 23 invocations sets up some kind of >> corrupt data that continues to get used. > >That could be one plausible explanation.

Re: [LKP] [lkp] [x86/hweight] 65ea11ec6a: will-it-scale.per_process_ops 9.3% improvement

On August 25, 2016 4:45:06 AM PDT, Borislav Petkov wrote: >On Thu, Aug 25, 2016 at 03:05:19AM -0700, H. Peter Anvin wrote: >> I'm wondering if one of those 23 invocations sets up some kind of >> corrupt data that continues to get used. > >That could be one plausible explanation. Look at what

Re: [LKP] [lkp] [x86/hweight] 65ea11ec6a: will-it-scale.per_process_ops 9.3% improvement

On Thu, Aug 25, 2016 at 03:05:19AM -0700, H. Peter Anvin wrote: > I'm wondering if one of those 23 invocations sets up some kind of > corrupt data that continues to get used. That could be one plausible explanation. Look at what calls __sw_hweight64: initmem_init numa_policy_init

Re: [LKP] [lkp] [x86/hweight] 65ea11ec6a: will-it-scale.per_process_ops 9.3% improvement

On Thu, Aug 25, 2016 at 03:05:19AM -0700, H. Peter Anvin wrote: > I'm wondering if one of those 23 invocations sets up some kind of > corrupt data that continues to get used. That could be one plausible explanation. Look at what calls __sw_hweight64: initmem_init numa_policy_init

Re: [LKP] [lkp] [x86/hweight] 65ea11ec6a: will-it-scale.per_process_ops 9.3% improvement

On August 25, 2016 2:22:14 AM PDT, Borislav Petkov wrote: >On Thu, Aug 18, 2016 at 06:11:39AM +0200, Borislav Petkov wrote: >> So if there's no bug, alternatives should replace all "call >> __sw_hweightXX" calls with POPCNT. So you shouldn't be even calling >> these functions and

Re: [LKP] [lkp] [x86/hweight] 65ea11ec6a: will-it-scale.per_process_ops 9.3% improvement

On August 25, 2016 2:22:14 AM PDT, Borislav Petkov wrote: >On Thu, Aug 18, 2016 at 06:11:39AM +0200, Borislav Petkov wrote: >> So if there's no bug, alternatives should replace all "call >> __sw_hweightXX" calls with POPCNT. So you shouldn't be even calling >> these functions and hitting that

Re: [LKP] [lkp] [x86/hweight] 65ea11ec6a: will-it-scale.per_process_ops 9.3% improvement

On Thu, Aug 18, 2016 at 06:11:39AM +0200, Borislav Petkov wrote: > So if there's no bug, alternatives should replace all "call > __sw_hweightXX" calls with POPCNT. So you shouldn't be even calling > these functions and hitting that path. > > Can you boot the kernel with "debug-alternative" and

Re: [LKP] [lkp] [x86/hweight] 65ea11ec6a: will-it-scale.per_process_ops 9.3% improvement

On Thu, Aug 18, 2016 at 06:11:39AM +0200, Borislav Petkov wrote: > So if there's no bug, alternatives should replace all "call > __sw_hweightXX" calls with POPCNT. So you shouldn't be even calling > these functions and hitting that path. > > Can you boot the kernel with "debug-alternative" and

Re: [LKP] [lkp] [x86/hweight] 65ea11ec6a: will-it-scale.per_process_ops 9.3% improvement

On Wed, Aug 17, 2016 at 08:54:11PM -0700, Huang, Ying wrote: > flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca > cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx > pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology >

Re: [LKP] [lkp] [x86/hweight] 65ea11ec6a: will-it-scale.per_process_ops 9.3% improvement

On Wed, Aug 17, 2016 at 08:54:11PM -0700, Huang, Ying wrote: > flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca > cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx > pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology >

Re: [LKP] [lkp] [x86/hweight] 65ea11ec6a: will-it-scale.per_process_ops 9.3% improvement

On August 17, 2016 8:45:13 PM PDT, Borislav Petkov wrote: >On Wed, Aug 17, 2016 at 03:29:04PM -0700, Huang, Ying wrote: >> branch-miss-rate decreased from ~0.30% to ~0.043%. >> >> So I guess there are some code alignment change, which caused >decreased >> branch miss rate. > >Hrrm,

Re: [LKP] [lkp] [x86/hweight] 65ea11ec6a: will-it-scale.per_process_ops 9.3% improvement

On August 17, 2016 8:45:13 PM PDT, Borislav Petkov wrote: >On Wed, Aug 17, 2016 at 03:29:04PM -0700, Huang, Ying wrote: >> branch-miss-rate decreased from ~0.30% to ~0.043%. >> >> So I guess there are some code alignment change, which caused >decreased >> branch miss rate. > >Hrrm, I still can't

Re: [LKP] [lkp] [x86/hweight] 65ea11ec6a: will-it-scale.per_process_ops 9.3% improvement

Borislav Petkov writes: > On Wed, Aug 17, 2016 at 03:29:04PM -0700, Huang, Ying wrote: >> branch-miss-rate decreased from ~0.30% to ~0.043%. >> >> So I guess there are some code alignment change, which caused decreased >> branch miss rate. > > Hrrm, I still can't imagine how that

Re: [LKP] [lkp] [x86/hweight] 65ea11ec6a: will-it-scale.per_process_ops 9.3% improvement

Borislav Petkov writes: > On Wed, Aug 17, 2016 at 03:29:04PM -0700, Huang, Ying wrote: >> branch-miss-rate decreased from ~0.30% to ~0.043%. >> >> So I guess there are some code alignment change, which caused decreased >> branch miss rate. > > Hrrm, I still can't imagine how that would happen

Re: [LKP] [lkp] [x86/hweight] 65ea11ec6a: will-it-scale.per_process_ops 9.3% improvement

On Wed, Aug 17, 2016 at 03:29:04PM -0700, Huang, Ying wrote: > branch-miss-rate decreased from ~0.30% to ~0.043%. > > So I guess there are some code alignment change, which caused decreased > branch miss rate. Hrrm, I still can't imagine how that would happen if the machine supports POPCNT and

Re: [LKP] [lkp] [x86/hweight] 65ea11ec6a: will-it-scale.per_process_ops 9.3% improvement

On Wed, Aug 17, 2016 at 03:29:04PM -0700, Huang, Ying wrote: > branch-miss-rate decreased from ~0.30% to ~0.043%. > > So I guess there are some code alignment change, which caused decreased > branch miss rate. Hrrm, I still can't imagine how that would happen if the machine supports POPCNT and

Re: [LKP] [lkp] [x86/hweight] 65ea11ec6a: will-it-scale.per_process_ops 9.3% improvement

Borislav Petkov writes: > On Tue, Aug 16, 2016 at 04:09:19PM -0700, H. Peter Anvin wrote: >> On August 16, 2016 10:16:35 AM PDT, Borislav Petkov wrote: >> >On Tue, Aug 16, 2016 at 09:59:00AM -0700, H. Peter Anvin wrote: >> >> Dang... >> > >> >Isn't 9.3% improvement a

Re: [LKP] [lkp] [x86/hweight] 65ea11ec6a: will-it-scale.per_process_ops 9.3% improvement

Borislav Petkov writes: > On Tue, Aug 16, 2016 at 04:09:19PM -0700, H. Peter Anvin wrote: >> On August 16, 2016 10:16:35 AM PDT, Borislav Petkov wrote: >> >On Tue, Aug 16, 2016 at 09:59:00AM -0700, H. Peter Anvin wrote: >> >> Dang... >> > >> >Isn't 9.3% improvement a good thing(tm) ? >> >>

Re: [lkp] [x86/hweight] 65ea11ec6a: will-it-scale.per_process_ops 9.3% improvement

On Tue, Aug 16, 2016 at 04:09:19PM -0700, H. Peter Anvin wrote: > On August 16, 2016 10:16:35 AM PDT, Borislav Petkov wrote: > >On Tue, Aug 16, 2016 at 09:59:00AM -0700, H. Peter Anvin wrote: > >> Dang... > > > >Isn't 9.3% improvement a good thing(tm) ? > > Yes, it's huge. The

Re: [lkp] [x86/hweight] 65ea11ec6a: will-it-scale.per_process_ops 9.3% improvement

On Tue, Aug 16, 2016 at 04:09:19PM -0700, H. Peter Anvin wrote: > On August 16, 2016 10:16:35 AM PDT, Borislav Petkov wrote: > >On Tue, Aug 16, 2016 at 09:59:00AM -0700, H. Peter Anvin wrote: > >> Dang... > > > >Isn't 9.3% improvement a good thing(tm) ? > > Yes, it's huge. The only explanation

Re: [lkp] [x86/hweight] 65ea11ec6a: will-it-scale.per_process_ops 9.3% improvement

On Tue, Aug 16, 2016 at 04:09:19PM -0700, H. Peter Anvin wrote: > On August 16, 2016 10:16:35 AM PDT, Borislav Petkov wrote: > >On Tue, Aug 16, 2016 at 09:59:00AM -0700, H. Peter Anvin wrote: > >> Dang... > > > >Isn't 9.3% improvement a good thing(tm) ? > > Yes, it's huge. The

Re: [lkp] [x86/hweight] 65ea11ec6a: will-it-scale.per_process_ops 9.3% improvement

On Tue, Aug 16, 2016 at 04:09:19PM -0700, H. Peter Anvin wrote: > On August 16, 2016 10:16:35 AM PDT, Borislav Petkov wrote: > >On Tue, Aug 16, 2016 at 09:59:00AM -0700, H. Peter Anvin wrote: > >> Dang... > > > >Isn't 9.3% improvement a good thing(tm) ? > > Yes, it's huge. The only explanation

Re: [lkp] [x86/hweight] 65ea11ec6a: will-it-scale.per_process_ops 9.3% improvement

On August 16, 2016 10:16:35 AM PDT, Borislav Petkov wrote: >On Tue, Aug 16, 2016 at 09:59:00AM -0700, H. Peter Anvin wrote: >> Dang... > >Isn't 9.3% improvement a good thing(tm) ? Yes, it's huge. The only explanation I could imagine is that scrambling %rdi caused the scheduler to

Re: [lkp] [x86/hweight] 65ea11ec6a: will-it-scale.per_process_ops 9.3% improvement

On August 16, 2016 10:16:35 AM PDT, Borislav Petkov wrote: >On Tue, Aug 16, 2016 at 09:59:00AM -0700, H. Peter Anvin wrote: >> Dang... > >Isn't 9.3% improvement a good thing(tm) ? Yes, it's huge. The only explanation I could imagine is that scrambling %rdi caused the scheduler to do completely

Re: [lkp] [x86/hweight] 65ea11ec6a: will-it-scale.per_process_ops 9.3% improvement

On Tue, Aug 16, 2016 at 09:59:00AM -0700, H. Peter Anvin wrote: > Dang... Isn't 9.3% improvement a good thing(tm) ? -- Regards/Gruss, Boris. ECO tip #101: Trim your mails when you reply. SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) --

Re: [lkp] [x86/hweight] 65ea11ec6a: will-it-scale.per_process_ops 9.3% improvement

On Tue, Aug 16, 2016 at 09:59:00AM -0700, H. Peter Anvin wrote: > Dang... Isn't 9.3% improvement a good thing(tm) ? -- Regards/Gruss, Boris. ECO tip #101: Trim your mails when you reply. SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) --

Re: [lkp] [x86/hweight] 65ea11ec6a: will-it-scale.per_process_ops 9.3% improvement

On August 16, 2016 7:26:43 AM PDT, kernel test robot wrote: > >FYI, we noticed a 9.3% improvement of will-it-scale.per_process_ops due >to commit: > >commit 65ea11ec6a82b1d44aba62b59e9eb20247e57c6e ("x86/hweight: Don't >clobber %rdi")

Re: [lkp] [x86/hweight] 65ea11ec6a: will-it-scale.per_process_ops 9.3% improvement

On August 16, 2016 7:26:43 AM PDT, kernel test robot wrote: > >FYI, we noticed a 9.3% improvement of will-it-scale.per_process_ops due >to commit: > >commit 65ea11ec6a82b1d44aba62b59e9eb20247e57c6e ("x86/hweight: Don't >clobber %rdi")