Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754546AbdDLOyN (ORCPT ); Wed, 12 Apr 2017 10:54:13 -0400 Received: from mga02.intel.com ([134.134.136.20]:12415 "EHLO mga02.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754484AbdDLOx6 (ORCPT ); Wed, 12 Apr 2017 10:53:58 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.37,191,1488873600"; d="scan'208";a="88237435" Date: Wed, 12 Apr 2017 11:02:28 -0400 From: Keith Busch To: kernel test robot Cc: Thomas Gleixner , linux-kernel@vger.kernel.org, linux-nvme@lists.infradead.org, Christoph Hellwig , lkp@01.org Subject: Re: [lkp-robot] [irq/affinity] 13c024422c: fsmark.files_per_sec -4.3% regression Message-ID: <20170412150227.GD623@localhost.localdomain> References: <20170330171255.GF20181@localhost.localdomain> <20170412013328.GC31394@yexl-desktop> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170412013328.GC31394@yexl-desktop> User-Agent: Mutt/1.7.0 (2016-08-17) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1323 Lines: 37 On Wed, Apr 12, 2017 at 09:33:28AM +0800, kernel test robot wrote: > > Greeting, > > FYI, we noticed a -4.3% regression of fsmark.files_per_sec due to commit: > > > commit: 13c024422cbb6dcc513667be9a2613b0f0de781a ("irq/affinity: Assign all CPUs a vector") > url: https://github.com/0day-ci/linux/commits/Keith-Busch/irq-affinity-Assign-all-CPUs-a-vector/20170401-035036 > > > in testcase: fsmark > on test machine: 72 threads Intel(R) Xeon(R) CPU E5-2699 v3 @ 2.30GHz with 128G memory > with following parameters: > > iterations: 8 > disk: 1SSD > nr_threads: 4 > fs: btrfs > filesize: 9B > test_size: 16G > sync_method: fsyncBeforeClose > nr_directories: 16d > nr_files_per_directory: 256fpd > cpufreq_governor: performance > > test-description: The fsmark is a file system benchmark to test synchronous write workloads, for example, mail servers workload. > test-url: https://sourceforge.net/projects/fsmark/ > > > Details are as below: > --------------------------------------------------------------------------------------------------> This wasn't supposed to change anything if all the nodes have the same number of CPU's. I've reached out to the 0-day team to get a little more information on the before/after smp affinity settings to see how this algorithm messed up the spread on this system.