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 Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id F04FAC54EBD for ; Fri, 13 Jan 2023 01:14:17 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:Cc:To:Subject:Message-ID:Date:From: References:In-Reply-To:MIME-Version:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=46AVD1YGBhX1XHJKb/7wPASssDDstMS/9mJ+JsXkj+k=; b=wLn3kQngmTz+Xx uDNS/q9D5zq+zYzsgcuz5lbPB29vABwncYqY778UO72/WEIc23TLgXhBBdoqBxHCzQTb8pzWNu+C8 ICxKEbpHg93EkgPN2s9h4nEujneIrxr1/uSPJUEwMBedMhiUhB0nvzmEmqom7f0dhhR9ph6HEeB/q Nq1zIxPOm3VJwy/jX1KMtrwoKGYoVnHKq2BTAllqJHTPdWbT+Vmn3/fYm1ShGQZuWT6KeCivtsDQV DMLzxhE9ZsxCdgtwMV1u8UcXLkeKG8B8V7CKQi+yZm63k5jOUjgbNw1d/Eplmmpn3sJhDRwg+wUHT BAh4T8tkghFjWlKE7npA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1pG8cv-0002tC-IU; Fri, 13 Jan 2023 01:13:01 +0000 Received: from mail-oo1-xc36.google.com ([2607:f8b0:4864:20::c36]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1pG8cn-0002rv-Ga for linux-arm-kernel@lists.infradead.org; Fri, 13 Jan 2023 01:12:54 +0000 Received: by mail-oo1-xc36.google.com with SMTP id m23-20020a4abc97000000b004bfe105c580so5246584oop.4 for ; Thu, 12 Jan 2023 17:12:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:references:in-reply-to :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=KV52lj2dmjkAsboEJSBjeC6RZgHMYA6025SgDDWUPjA=; b=jQvh9BtcxioCFwJqPAATwW7XH20JrEE6xXt0uzDoSMoX+gAkfBk5NYfs01zNyx9S5b Kqg6QYjRmels0qpVta6XvOZOYsoykIj4EIXFPJqVgP63tx6rtuiaB8AlNIT8Mpot0vgF 4N1QBxbdVuSpLUI8CVeWhpK6VAzwduLg8RX5Ys6wprCOZOihjr8W6hn3Ub4FWu1ylkV6 cH8XtbAdQiTcLcciL61RdQLCyYYaoEHgNQCbw/hNaz/7lG+1m6g2I6fsfeIQq8E6s9ji zQ/01gQyWcuzOEkTDBsoze++PVjAnJBV2q2YrfGYmCwLQUdjP/QiGa2y37BoMLXts2XQ 76qw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:references:in-reply-to :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=KV52lj2dmjkAsboEJSBjeC6RZgHMYA6025SgDDWUPjA=; b=HjPnDFPb5xp3JOHmcN5vEdto8m/Hei8OzzzAlLxgLDuXLAk4/UgIRy0FG2GofXDrG3 DRpMzSzelQWOjF1NSJYDhOl15Wb4ovngOi6v2dvG9zpQf55olkiB2Np4Uvr+mh5Amikj tOFFVVXq8sFnCR3etf990wiWzm+maps8bohsXoa0NmLuOYT7NHItEcm91+FjVgGSXgjt dyNq2c3TosWIIBdi7Kg4THqaZF74K8SVIfUA282/C1ZmUqUOQ1SEwcI9TVz1lhcc6jDV Ez9Ewvyx1jzsoJLyTGkv+h2g5izdWj4tB+SQfmmAsksBFiswBKfXcKRwcB5zhkdF5+vC ZMew== X-Gm-Message-State: AFqh2ko0bjWmTO3PqFoTj4pAehh99HXsNwcHugQ/oZOr/evMDid8fV2r EUh8sweLN9zpIQXy4/kg80QoyqiF+Psg41Q6FA0= X-Google-Smtp-Source: AMrXdXuWIXZj7GTqE2vZ82Tol/3lPrC2YrNkJMh4/eYlDNwugZKGviKH9kvg1/JBDmDJLMmE/uNj0l3V8UWTfh5vAzE= X-Received: by 2002:a05:6820:188d:b0:4a0:78a0:bb6a with SMTP id bm13-20020a056820188d00b004a078a0bb6amr3948746oob.4.1673572371746; Thu, 12 Jan 2023 17:12:51 -0800 (PST) MIME-Version: 1.0 Received: by 2002:ac9:77d5:0:b0:491:8368:9bdd with HTTP; Thu, 12 Jan 2023 17:12:50 -0800 (PST) In-Reply-To: References: From: Mateusz Guzik Date: Fri, 13 Jan 2023 02:12:50 +0100 Message-ID: Subject: Re: lockref scalability on x86-64 vs cpu_relax To: Linus Torvalds Cc: linux-arch , Catalin Marinas , Will Deacon , Michael Ellerman , linux-fsdevel@vger.kernel.org, viro@zeniv.linux.org.uk, Jan Glauber , tony.luck@intel.com, Linux ARM , linuxppc-dev X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20230112_171253_597307_50479DF6 X-CRM114-Status: GOOD ( 25.96 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On 1/13/23, Linus Torvalds wrote: > Side note on your access() changes - if it turns out that you can > remove all the cred games, we should possibly then revert my old > commit d7852fbd0f04 ("access: avoid the RCU grace period for the > temporary subjective credentials") which avoided the biggest issue > with the unnecessary cred switching. > > I *think* access() is the only user of that special 'non_rcu' thing, > but it is possible that the whole 'non_rcu' thing ends up mattering > for cases where the cred actually does change because euid != uid (ie > suid programs), so this would need a bit more effort to do performance > testing on. > I don't think the games are avoidable. For one I found non-root processes with non-empty cap_effective even on my laptop, albeit I did not check how often something like this is doing access(). Discussion for another time. > On Thu, Jan 12, 2023 at 5:36 PM Mateusz Guzik wrote: >> All that said, I think the thing to do here is to replace cpu_relax >> with a dedicated arch-dependent macro, akin to the following: > > I would actually prefer just removing it entirely and see if somebody > else hollers. You have the numbers to prove it hurts on real hardware, > and I don't think we have any numbers to the contrary. > > So I think it's better to trust the numbers and remove it as a > failure, than say "let's just remove it on x86-64 and leave everybody > else with the potentially broken code" > [snip] > Then other architectures can try to run their numbers, and only *if* > it then turns out that they have a reason to do something else should > we make this conditional and different on different architectures. > > Let's try to keep the code as common as possibly until we have hard > evidence for special cases, in other words. > I did not want to make such a change without redoing the ThunderX2 benchmark, or at least something else arm64-y. I may be able to bench it tomorrow on whatever arm-y stuff can be found on Amazon's EC2, assuming no arm64 people show up with their results. Even then IMHO the safest route is to patch it out on x86-64 and give other people time to bench their archs as they get around to it, and ultimately whack the thing if it turns out nobody benefits from it. I would say beats backpedaling on the removal, but I'm not going to fight for it. That said, does waiting for arm64 numbers and/or producing them for the removal commit message sound like a plan? If so, I'll post soon(tm). -- Mateusz Guzik _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel