From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753950AbdLFBoG (ORCPT ); Tue, 5 Dec 2017 20:44:06 -0500 Received: from mga06.intel.com ([134.134.136.31]:49312 "EHLO mga06.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753881AbdLFBn4 (ORCPT ); Tue, 5 Dec 2017 20:43:56 -0500 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.45,366,1508828400"; d="scan'208";a="184445791" From: "Lu, Aaron" To: "bcodding@redhat.com" , "jlayton@redhat.com" CC: "torvalds@linux-foundation.org" , "linux-kernel@vger.kernel.org" , "lkp@01.org" , "Ye, Xiaolong" Subject: Re: [LKP] [lkp-robot] [fs/locks] 52306e882f: stress-ng.lockofd.ops_per_sec -11% regression Thread-Topic: [LKP] [lkp-robot] [fs/locks] 52306e882f: stress-ng.lockofd.ops_per_sec -11% regression Thread-Index: AQHTODCAVd0mr2ftTEC3hB+uyzNGuKMKVE6AgCpXQwD//86fAIAA9rSA Date: Wed, 6 Dec 2017 01:43:52 +0000 Message-ID: <1512524641.18934.2.camel@intel.com> References: <20170928080223.GX17200@yexl-desktop> <20171108072233.GA3816@intel.com> <20171205055746.GA13514@intel.com> <1512471662.4125.2.camel@redhat.com> In-Reply-To: <1512471662.4125.2.camel@redhat.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.239.159.135] Content-Type: text/plain; charset="utf-8" Content-ID: MIME-Version: 1.0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by nfs id vB61iDil030494 On Tue, 2017-12-05 at 06:01 -0500, Jeff Layton wrote: > On Tue, 2017-12-05 at 13:57 +0800, Aaron Lu wrote: > > On Wed, Nov 08, 2017 at 03:22:33PM +0800, Aaron Lu wrote: > > > On Thu, Sep 28, 2017 at 04:02:23PM +0800, kernel test robot wrote: > > > > > > > > Greeting, > > > > > > > > FYI, we noticed a -11% regression of stress-ng.lockofd.ops_per_sec due to commit: > > > > > > > > > > > > commit: 52306e882f77d3fd73f91435c41373d634acc5d2 ("fs/locks: Use allocation rather than the stack in fcntl_getlk()") > > > > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git master > > > > > > It's been a while, I wonder what do you think of this regression? > > > > > > The test stresses byte-range locks AFAICS and since the commit uses > > > dynamic allocation instead of stack for the 'struct file_lock', it sounds > > > natural the performance regressed for this test. > > > > > > Now the question is, do we care about the performance regression here? > > > > Appreciated it if you can share your opinion on this, thanks. > > > > Regards, > > Aaron > > > > Sorry I missed your earlier mail about this. My feeling is to not worry Never mind :) > about it. struct file_lock is rather large, so putting it on the stack > was always a bit dangerous, and F_GETLK is a rather uncommon operation > anyway. > > That said, if there are real-world workloads that have regressed because > of this patch, I'm definitely open to backing it out. > > Does anyone else have opinions on the matter? Your comments makes sense to me, thanks for the reply.