From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-11.6 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,INCLUDES_PATCH,MAILING_LIST_MULTI, SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 63287C433E1 for ; Fri, 21 Aug 2020 16:03:28 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 38B88208DB for ; Fri, 21 Aug 2020 16:03:28 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1598025808; bh=EV/GR+9VB23wO4HYAr+8yBHz5vSm7Ev/KRXR37JYI2g=; h=Date:From:To:Cc:Subject:References:In-Reply-To:List-ID:From; b=JwpH9lfwRoqTDqBjfyUpix/i7h1l8IC1twz0BCY4/WfRH66VAYepHPZwtTxbWP9HS 3OBeWF0W9x6BNIGaEEUfq2CJ7TT2BSi3KzU7Bc+GKlbhPCR0/dzrezS0XqfqrrcwjI +gL6Zru0x15xZdY4iYb5Tw6hF9zM9dirQ+Jae0Eg= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1725820AbgHUQDV (ORCPT ); Fri, 21 Aug 2020 12:03:21 -0400 Received: from mail.kernel.org ([198.145.29.99]:35600 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725866AbgHUQC6 (ORCPT ); Fri, 21 Aug 2020 12:02:58 -0400 Received: from willie-the-truck (236.31.169.217.in-addr.arpa [217.169.31.236]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 363A7207BB; Fri, 21 Aug 2020 16:02:56 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1598025777; bh=EV/GR+9VB23wO4HYAr+8yBHz5vSm7Ev/KRXR37JYI2g=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=ImovsCZrJ/tdgS2ncCQiTS/L8yCwYE9ohFeJBAvirJKdRqeaxw8/m9aRr5h2sGaHC XgEWMfxB3M1PQKRQRdjLE03otqTFiLJPx5bVVQi35AAXT1D6p1YlIv8iZWEuFzqiAP FPJxlahOObcq2GKrNbYshgjpdDJ/xEuoFZEgWaJk= Date: Fri, 21 Aug 2020 17:02:53 +0100 From: Will Deacon To: Shaokun Zhang Cc: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, Mark Rutland , Peter Zijlstra , Alexander Viro , Boqun Feng , Yuqi Jin Subject: Re: [PATCH RESEND] fs: Move @f_count to different cacheline with @f_mode Message-ID: <20200821160252.GC21517@willie-the-truck> References: <1592987548-8653-1-git-send-email-zhangshaokun@hisilicon.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1592987548-8653-1-git-send-email-zhangshaokun@hisilicon.com> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Jun 24, 2020 at 04:32:28PM +0800, Shaokun Zhang wrote: > get_file_rcu_many, which is called by __fget_files, has used > atomic_try_cmpxchg now and it can reduce the access number of the global > variable to improve the performance of atomic instruction compared with > atomic_cmpxchg. > > __fget_files does check the @f_mode with mask variable and will do some > atomic operations on @f_count, but both are on the same cacheline. > Many CPU cores do file access and it will cause much conflicts on @f_count. > If we could make the two members into different cachelines, it shall relax > the siutations. > > We have tested this on ARM64 and X86, the result is as follows: > Syscall of unixbench has been run on Huawei Kunpeng920 with this patch: > 24 x System Call Overhead 1 > > System Call Overhead 3160841.4 lps (10.0 s, 1 samples) > > System Benchmarks Partial Index BASELINE RESULT INDEX > System Call Overhead 15000.0 3160841.4 2107.2 > ======== > System Benchmarks Index Score (Partial Only) 2107.2 > > Without this patch: > 24 x System Call Overhead 1 > > System Call Overhead 2222456.0 lps (10.0 s, 1 samples) > > System Benchmarks Partial Index BASELINE RESULT INDEX > System Call Overhead 15000.0 2222456.0 1481.6 > ======== > System Benchmarks Index Score (Partial Only) 1481.6 > > And on Intel 6248 platform with this patch: > 40 CPUs in system; running 24 parallel copies of tests > > System Call Overhead 4288509.1 lps (10.0 s, 1 samples) > > System Benchmarks Partial Index BASELINE RESULT INDEX > System Call Overhead 15000.0 4288509.1 2859.0 > ======== > System Benchmarks Index Score (Partial Only) 2859.0 > > Without this patch: > 40 CPUs in system; running 24 parallel copies of tests > > System Call Overhead 3666313.0 lps (10.0 s, 1 samples) > > System Benchmarks Partial Index BASELINE RESULT INDEX > System Call Overhead 15000.0 3666313.0 2444.2 > ======== > System Benchmarks Index Score (Partial Only) 2444.2 > > Cc: Will Deacon > Cc: Mark Rutland > Cc: Peter Zijlstra > Cc: Alexander Viro > Cc: Boqun Feng > Signed-off-by: Yuqi Jin > Signed-off-by: Shaokun Zhang > --- > include/linux/fs.h | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/include/linux/fs.h b/include/linux/fs.h > index 3f881a892ea7..0faeab5622fb 100644 > --- a/include/linux/fs.h > +++ b/include/linux/fs.h > @@ -955,7 +955,6 @@ struct file { > */ > spinlock_t f_lock; > enum rw_hint f_write_hint; > - atomic_long_t f_count; > unsigned int f_flags; > fmode_t f_mode; > struct mutex f_pos_lock; > @@ -979,6 +978,7 @@ struct file { > struct address_space *f_mapping; > errseq_t f_wb_err; > errseq_t f_sb_err; /* for syncfs */ > + atomic_long_t f_count; > } __randomize_layout > __attribute__((aligned(4))); /* lest something weird decides that 2 is OK */ Hmm. So the microbenchmark numbers look lovely, but: - What impact does it actually have for real workloads? - How do we avoid regressing performance by innocently changing the struct again later on? - This thing is tagged with __randomize_layout, so it doesn't help anybody using that crazy plugin - What about all the other atomics and locks that share cachelines? Will