From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932327AbcHJX65 (ORCPT ); Wed, 10 Aug 2016 19:58:57 -0400 Received: from mga09.intel.com ([134.134.136.24]:5280 "EHLO mga09.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750882AbcHJX6y (ORCPT ); Wed, 10 Aug 2016 19:58:54 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.28,502,1464678000"; d="scan'208";a="863371040" From: "Huang\, Ying" To: Linus Torvalds Cc: Dave Chinner , Wu Fengguang , Bob Peterson , LKML , LKP , Christoph Hellwig Subject: Re: [LKP] [lkp] [xfs] 68a9f5e700: aim7.jobs-per-min -13.6% regression References: <20160809143359.GA11220@yexl-desktop> <20160810230840.GS16044@dastard> Date: Wed, 10 Aug 2016 16:58:17 -0700 In-Reply-To: (Linus Torvalds's message of "Wed, 10 Aug 2016 16:51:05 -0700") Message-ID: <87eg5w18iu.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 Hi, Linus, Linus Torvalds writes: > On Wed, Aug 10, 2016 at 4:08 PM, Dave Chinner wrote: >> >> That, to me, says there's a change in lock contention behaviour in >> the workload (which we know aim7 is good at exposing). i.e. the >> iomap change shifted contention from a sleeping lock to a spinning >> lock, or maybe we now trigger optimistic spinning behaviour on a >> lock we previously didn't spin on at all. > > Hmm. Possibly. I reacted to the lower cpu load number, but yeah, I > could easily imagine some locking primitive difference too. > >> We really need instruction level perf profiles to understand >> this - I don't have a machine with this many cpu cores available >> locally, so I'm not sure I'm going to be able to make any progress >> tracking it down in the short term. Maybe the lkp team has more >> in-depth cpu usage profiles they can share? > > Yeah, I've occasionally wanted to see some kind of "top-25 kernel > functions in the profile" thing. That said, when the load isn't all > that familiar, the profiles usually are not all that easy to make > sense of either. But comparing the before and after state might give > us clues. I have started perf-profile data collection, will send out the comparison result soon. Best Regards, Huang, Ying From mboxrd@z Thu Jan 1 00:00:00 1970 Content-Type: multipart/mixed; boundary="===============2953112894966067373==" MIME-Version: 1.0 From: Huang, Ying To: lkp@lists.01.org Subject: Re: [xfs] 68a9f5e700: aim7.jobs-per-min -13.6% regression Date: Wed, 10 Aug 2016 16:58:17 -0700 Message-ID: <87eg5w18iu.fsf@yhuang-mobile.sh.intel.com> In-Reply-To: List-Id: --===============2953112894966067373== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Hi, Linus, Linus Torvalds writes: > On Wed, Aug 10, 2016 at 4:08 PM, Dave Chinner wro= te: >> >> That, to me, says there's a change in lock contention behaviour in >> the workload (which we know aim7 is good at exposing). i.e. the >> iomap change shifted contention from a sleeping lock to a spinning >> lock, or maybe we now trigger optimistic spinning behaviour on a >> lock we previously didn't spin on at all. > > Hmm. Possibly. I reacted to the lower cpu load number, but yeah, I > could easily imagine some locking primitive difference too. > >> We really need instruction level perf profiles to understand >> this - I don't have a machine with this many cpu cores available >> locally, so I'm not sure I'm going to be able to make any progress >> tracking it down in the short term. Maybe the lkp team has more >> in-depth cpu usage profiles they can share? > > Yeah, I've occasionally wanted to see some kind of "top-25 kernel > functions in the profile" thing. That said, when the load isn't all > that familiar, the profiles usually are not all that easy to make > sense of either. But comparing the before and after state might give > us clues. I have started perf-profile data collection, will send out the comparison result soon. Best Regards, Huang, Ying --===============2953112894966067373==--