From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753376AbcHQW3G (ORCPT ); Wed, 17 Aug 2016 18:29:06 -0400 Received: from mga14.intel.com ([192.55.52.115]:33146 "EHLO mga14.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752834AbcHQW3E (ORCPT ); Wed, 17 Aug 2016 18:29:04 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.28,535,1464678000"; d="scan'208";a="867217086" From: "Huang\, Ying" To: Borislav Petkov Cc: "H. Peter Anvin" , Denys Vlasenko , Peter Zijlstra , Brian Gerst , LKML , Andy Lutomirski , , Thomas Gleixner , Linus Torvalds , Ingo Molnar , Ville =?utf-8?B?U3lyasOkbMOk?= Subject: Re: [LKP] [lkp] [x86/hweight] 65ea11ec6a: will-it-scale.per_process_ops 9.3% improvement References: <20160816142642.GA24206@yexl-desktop> <9FF32F53-5EF8-40D4-B696-A30FDF7201E1@zytor.com> <20160816171635.GA10542@nazgul.tnic> <796A2A72-06B7-4B3D-AA38-DF558FC75857@zytor.com> <20160817054605.GA6728@nazgul.tnic> Date: Wed, 17 Aug 2016 15:29:04 -0700 In-Reply-To: <20160817054605.GA6728@nazgul.tnic> (Borislav Petkov's message of "Wed, 17 Aug 2016 07:46:05 +0200") Message-ID: <87r39n58sv.fsf@yhuang-mobile.sh.intel.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=ascii Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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) ? >> >> Yes, it's huge. The only explanation I could imagine is that scrambling %rdi caused the scheduler to do completely the wrong thing. > > I'm questioning the validity, actually. Report says test machine was > Sandy Bridge-EP and I'd bet good money this one has POPCNT support so > how are we even hitting that __sw_hweight64() path, at all? We done 8 tests for the base and 4 tests for the head, and the result is quite stable. I found there is another change between the two comments, base: "perf-stat.branch-miss-rate": [ 0.3089533646503185, 0.3099821038600304, 0.3123762964028104, 0.311511881793534, 0.31231973343587144, 0.3096478429327263, 0.31166037272389924, 0.3097364392684626 ], first bad commit: "perf-stat.branch-miss-rate": [ 0.039853905034485354, 0.0402472142423231, 0.04380682345704418, 0.04319082390667179 ], 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. Best Regards, Huang, Ying