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 kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 0E324C678DB for ; Mon, 6 Mar 2023 01:03:41 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 2FD486B0072; Sun, 5 Mar 2023 20:03:41 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 2ABF16B0073; Sun, 5 Mar 2023 20:03:41 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 173BB6B0074; Sun, 5 Mar 2023 20:03:41 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 04DBD6B0072 for ; Sun, 5 Mar 2023 20:03:41 -0500 (EST) Received: from smtpin27.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id CE28E120213 for ; Mon, 6 Mar 2023 01:03:40 +0000 (UTC) X-FDA: 80536675800.27.C85B2ED Received: from r3-19.sinamail.sina.com.cn (r3-19.sinamail.sina.com.cn [202.108.3.19]) by imf18.hostedemail.com (Postfix) with ESMTP id C72BB1C001A for ; Mon, 6 Mar 2023 01:03:37 +0000 (UTC) Authentication-Results: imf18.hostedemail.com; dkim=none; dmarc=none; spf=pass (imf18.hostedemail.com: domain of hdanton@sina.com designates 202.108.3.19 as permitted sender) smtp.mailfrom=hdanton@sina.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1678064619; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=3Qamn0/KKbGkN4bPqAxdF965o9PhYNtiKv3ONBbJXA4=; b=j7vPF54JwrKRlsa6XbL7TChS2618D4Wz43P/WaG2sN2hiMFDrFsKrH2mz0OIwfjNxjGOF8 V9i8qqlst6kOxasVYI+HNq0rPE83NNte0y9CG1bbrh9iCOu7wOmqOn6dXBPZiNtbDU4ww8 0n0pAk4pBen5po41q378mPJqhmHTTB0= ARC-Authentication-Results: i=1; imf18.hostedemail.com; dkim=none; dmarc=none; spf=pass (imf18.hostedemail.com: domain of hdanton@sina.com designates 202.108.3.19 as permitted sender) smtp.mailfrom=hdanton@sina.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1678064619; a=rsa-sha256; cv=none; b=k0sL5/QI/l03moR9+IDJmB08GT6fxtRmo30c+Ngh+k2h9PQF5/FvJwPcSgubc++JPZe1pN CxVKkOjt6dpwaAkjgRT/pu1EzP4DRcos7yfczAzO4Pf13keaOEz3FEI8to9KT/ng6JtvTY khKuRSdbkz2zAxzGqQD2RLaKl17lxO4= Received: from unknown (HELO localhost.localdomain)([114.249.61.130]) by sina.com (172.16.97.35) with ESMTP id 64053BD100024E16; Mon, 6 Mar 2023 09:03:15 +0800 (CST) X-Sender: hdanton@sina.com X-Auth-ID: hdanton@sina.com X-SMAIL-MID: 8072415073543 From: Hillf Danton To: Steven Rostedt Cc: John Stultz , LKML , Wei Wang , Midas Chien , "Chunhui Li (=?UTF-8?B?5p2O5pil6L6J?=)" , Kees Cook , Anton Vorontsov , "Guilherme G. Piccoli" , Tony Luck , linux-mm@kvack.org Subject: Re: [PATCH v2] pstore: Revert pmsg_lock back to a normal mutex Date: Mon, 6 Mar 2023 09:03:23 +0800 Message-Id: <20230306010323.2909-1-hdanton@sina.com> In-Reply-To: <20230305113632.26de0a4d@gandalf.local.home> References: <20230302062741.483079-1-jstultz@google.com> <20230304031029.3037914-1-jstultz@google.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Rspam-User: X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: C72BB1C001A X-Stat-Signature: rpwbr3xs8fn86gu8j3genkexjjeaht45 X-HE-Tag: 1678064617-5733 X-HE-Meta: U2FsdGVkX1/julS8UPWEW6N6IXHZZ0N0HaTayN5qSQGVppG4dTzcE3ZofRtNeMo6///86NS1jD/+0Lh83/qAKXVlZXwfYHmX4GZELtBh85sp0L/vIY28faKxx8CQHnRI3HVchxnL70G5ocaiy5LZCiwr8X5RPJqouswuZN876Wm3aVpzD7HNzZUBQtXSsbYvXDmKTZbywFFx7C4KtqwsurNwFNDN/+Clc1xqU19YKcTinnbccgDGcgdqxZNLQbq9DqM98cATf1FjBxNYPHhpFSoZ+IGAs/D02Tki4Uye8RQ0AGqnFL5/75hQjsoYu9Bwps1soGXpHpNP4HDaEn3yDasCeXuql0NSaXFx1Ru5rRl/XZRY7W63sKX0Aqg7ZD/dGwjJjbtWBaJGro3X2IQp/brFk4EdcimVbmeJy0uohA9b2MZf06i64GG9qmERb/ALNLgVkMKtDxDENeKT+sjBjIWeR619/UT0GUtf7nA2osLn+TgCw/Sq0v0r9fBtXgCEikdx8ZuHB7jqPpJXiy04JP833LbmyNtF6Nm8ZrGk0wOgo2Qxc+ywGV8kiJPQLaSChL66oMHH0bDIURXZGhVfFJh7xl9LuPCzPCwOoZM9QDzbNJh9UzOUL74q6OI7g5zS9mZz4WcN6GpjfQqMPLTrPYwhb5dyMnaM1FE5IZMWVSzbIJx8WWSf4V3MP8cccWC0PG2iHnBlh2lk19Id9tLTbRhsAR8Tk/E2zF1r0IMBtB/HMNBSPEHlUrsCSv1sOzhoxp+XLAzTluzjB3KJRvTvNER1YdY/BbKlrh16dWrvZGKorVPjFzKMfi8bvqyyVYkb3H3GhUp/Ck/FFGwajAC7giolE1B+84Kl0YWAz/EaD9nZcNJv9X0qyGWnUq7OvusR8EbKmpyYFfW+73p4JO6RySNHy9PDk+9ZaC1Xqrcz7rHGGy4rANjGtRngeSUl1NgtJi5JDkkxkGMU47EYaDn Deh25jKo Ra5kabarpWPJie3jPFgU9pvmaLYxx3l0T6yhs9huNuPqmVP+f3NZc9AnADJgygsIYgnORDQfh7NUQdMJ3Y7ZLJgfxjog3JIbNLs7USLD+U4iZL0lTdVRCXdJMl3YY/0ylXM2INMGDdBwblP0XVXxrqdyT/e2nN4K038WpHBa4UzNT55F9GrLarsP4gk//1v+hRm7Uggp6lu7NCySRNRpGNosK6UKFYrRAYl7D X-Bogosity: Ham, tests=bogofilter, spamicity=0.000166, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Sun, 5 Mar 2023 11:36:32 -0500 Steven Rostedt > On Sat, 4 Mar 2023 03:10:29 +0000 John Stultz wrote: > > > This reverts commit 76d62f24db07f22ccf9bc18ca793c27d4ebef721. > > > > So while priority inversion on the pmsg_lock is an occasional > > problem that an rt_mutex would help with, in uses where logging > > is writing to pmsg heavily from multiple threads, the pmsg_lock > > can be heavily contended. > > > > Normal mutexes can do adaptive spinning, which keeps the > > contention overhead fairly low maybe adding on the order of 10s > > of us delay waiting, but the slowpath w/ rt_mutexes makes the > > blocked tasks sleep & wake. This makes matters worse when there > > is heavy contentention, as it just allows additional threads to > > run and line up to try to take the lock. > > That is incorrect. rt_mutexes have pretty much the same adaptive spinning > as normal mutexes. So that is *not* the reason for the difference in > performance, and should not be stated so in this change log. > > The difference between rt_mutex and normal mutex, is that the rt_mutex will > trigger priority inheritance. Perhaps on high contention, that makes a > difference. But do not state it's because rt_mutex does not have adaptive > spinning, because it most definitely does. Another difference between rt_mutex and mutex is that mutex has another optimistic spin with the first waiter ignored, and that can be tested by simply skipping it. Perhaps because of the fact that it makes no sense for other waiters than the first one to spin on owner in rt context. PS what sense made by spinning on owner until need_resched() with preempt disabled in the non-rt context?