Received: by 2002:a05:6a10:22f:0:0:0:0 with SMTP id 15csp696901pxk; Sun, 30 Aug 2020 20:22:35 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxQqS32YoZchw9y5kpBfyIAihiLk+QxCDxbp8Wr/nuI+cVOr/nxOXMnxMwUok4ZzgiJg89o X-Received: by 2002:aa7:de03:: with SMTP id h3mr4118995edv.232.1598844154901; Sun, 30 Aug 2020 20:22:34 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1598844154; cv=none; d=google.com; s=arc-20160816; b=sbvPmYK0DyygfxItUq3l46yVuUua+mknMiocwQhc1jKATvbAnuY+2ca0SQN84/FKpx uy5RzIkmwcj8vm88xvz22CyKvYXJmyC9p7PYJ0gwRWs2JQne/qsC2Cxgls/8ecfgbJtX Wu73uM3Q2hh6/hBomLrwUesbU10Qb+ZmTAsQAT9Irz1wvXC+ByHSfdsCQCsUYsN4yKCA on56eKjyV1R6PIxnOAiUgTlEbKijlL3JRi3+Q6ZkJy4kNo3fN9V9HuIS5YgyQwZSfOq2 5BzG4wnKfMlY5cGjkKu24YX/QwKN+IPHAOJQCt3607Qf73zTtqr6mKmJWmjBRilBq7kc uVSw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date; bh=/sg910ZmxCYa+8hqv22GmqSpe+yLccyZJqVylN3XgsQ=; b=LboHtT1Nr86z6fgYfM3pHYMLDaKOKN/olRBPeJhctts7TzJX/SPzfXXIAKnSA4Fhv3 ObnFsFkGYLjN3s0QLC/jDcOk4Tml2Ja8/y8Z6I3hDBMAGMw0ioBlPH8Nq2PS3SRFAfiC Z94ARVyRmYzsa+3RNYKEWuzGuX+Iuw49ssY0Zx87/7SjxaNFULiZwiQ2jV3kS7XTQV0Y 3ODhd5wnV6739Zjb0z53S64RFHrpuiDsp7gQN+Bt/zQmBsW1rtyH72612fnANM6Hf1Sr d86PHBHhxzWZlQnFDYd5uF8ygkYyl4oW3SCBxSBLXL3Cvx2VJx+5MaQeZ1U0D2Z+Uf+B kMMA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id h27si3905788edj.263.2020.08.30.20.22.12; Sun, 30 Aug 2020 20:22:34 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727819AbgHaDVe (ORCPT + 99 others); Sun, 30 Aug 2020 23:21:34 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:54678 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726838AbgHaDVd (ORCPT ); Sun, 30 Aug 2020 23:21:33 -0400 Received: from ZenIV.linux.org.uk (zeniv.linux.org.uk [IPv6:2002:c35c:fd02::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 16326C061573; Sun, 30 Aug 2020 20:21:32 -0700 (PDT) Received: from viro by ZenIV.linux.org.uk with local (Exim 4.92.3 #3 (Red Hat Linux)) id 1kCaNr-007qZv-1n; Mon, 31 Aug 2020 03:21:27 +0000 Date: Mon, 31 Aug 2020 04:21:27 +0100 From: Al Viro To: Shaokun Zhang Cc: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, Yuqi Jin , kernel test robot , Will Deacon , Mark Rutland , Peter Zijlstra , Boqun Feng Subject: Re: [NAK] Re: [PATCH] fs: Optimized fget to improve performance Message-ID: <20200831032127.GW1236603@ZenIV.linux.org.uk> References: <1598523584-25601-1-git-send-email-zhangshaokun@hisilicon.com> <20200827142848.GZ1236603@ZenIV.linux.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Aug 31, 2020 at 09:43:31AM +0800, Shaokun Zhang wrote: > How about this? We try to replace atomic_cmpxchg with atomic_add to improve > performance. The atomic_add does not check the current f_count value. > Therefore, the number of online CPUs is reserved to prevent multi-core > competition. No. Really, really - no. Not unless you can guarantee that process on another CPU won't lose its timeslice, ending up with more than one increment happening on the same CPU - done by different processes scheduled there, one after another. If you have some change of atomic_long_add_unless(), do it there. And get it past the arm64 folks. get_file_rcu() is nothing special in that respect *AND* it has to cope with any architecture out there. BTW, keep in mind that there's such thing as a KVM - race windows are much wider there, since a thread representing a guest CPU might lose its timeslice whenever the host feels like that. At which point you get a single instruction on a guest CPU taking longer than many thousands of instructions on another CPU of the same guest. AFAIK, arm64 does support KVM with SMP guests.