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 8C50EC433F5 for ; Fri, 17 Dec 2021 19:49:12 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id D78206B0071; Fri, 17 Dec 2021 14:49:01 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id D28116B0073; Fri, 17 Dec 2021 14:49:01 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id BEFA16B0074; Fri, 17 Dec 2021 14:49:01 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0165.hostedemail.com [216.40.44.165]) by kanga.kvack.org (Postfix) with ESMTP id AF1456B0071 for ; Fri, 17 Dec 2021 14:49:01 -0500 (EST) Received: from smtpin14.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 7CC1881216 for ; Fri, 17 Dec 2021 19:48:51 +0000 (UTC) X-FDA: 78928324062.14.6C110D8 Received: from galois.linutronix.de (Galois.linutronix.de [193.142.43.55]) by imf04.hostedemail.com (Postfix) with ESMTP id EEAD240022 for ; Fri, 17 Dec 2021 19:48:50 +0000 (UTC) Date: Fri, 17 Dec 2021 20:48:47 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1639770528; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=MOhtWEVpE/nHvAfkcQxgjTO8DE1E/CE1cP2TvinWtt8=; b=usmzDClfjRh8F0bmnhmCivgUEzP3w2hcvpAvIrtYeBpsuLRJn+4DKo6fxqVSJatueqh/bL y1U2c4vzTmXRimDg8GVoBZvKtFqEsvVdMgGej6G+EsDFhT6W1diHNgOIC0KfMfDjz5E2FR LWiq5pgDeVvuMmhGNiV9JI4DhVFmCJsTUFwyFHUab0bBZlhSSIZ2p4TXkp81D4DCO0Q8/D EuJEQqKeReqTl4+hXBoQ8YifN5FDSYOaMWrWNq9b2jedjnGk4vLa7oJhW6jbL2Ajeycnmm xF2VpEjm7wkrWwBTi+0oC4IPzUPaxG3GIo2P4qGbXGEE7KUOGmmWiY2Hg7lQqQ== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1639770528; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=MOhtWEVpE/nHvAfkcQxgjTO8DE1E/CE1cP2TvinWtt8=; b=/FtWHAeSunsf+hn8FNtZSk94a8f3FndZKtc38HIXjF5iIq4qp6jb4YV269837n+ncw/jYU wuiXPn983+tX6xDQ== From: Sebastian Andrzej Siewior To: Waiman Long Cc: Johannes Weiner , Michal Hocko , Vladimir Davydov , Andrew Morton , linux-kernel@vger.kernel.org, cgroups@vger.kernel.org, linux-mm@kvack.org, Thomas Gleixner Subject: Re: [PATCH-next v3] mm/memcg: Properly handle memcg_stock access for PREEMPT_RT Message-ID: References: <20211214144412.447035-1-longman@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: EEAD240022 X-Stat-Signature: c414xtcjhbnyn616hqzszt7bfmhecu1e Authentication-Results: imf04.hostedemail.com; dkim=pass header.d=linutronix.de header.s=2020 header.b=usmzDClf; dkim=pass header.d=linutronix.de header.s=2020e header.b="/FtWHAeS"; spf=pass (imf04.hostedemail.com: domain of bigeasy@linutronix.de designates 193.142.43.55 as permitted sender) smtp.mailfrom=bigeasy@linutronix.de; dmarc=pass (policy=none) header.from=linutronix.de X-Rspamd-Server: rspam10 X-HE-Tag: 1639770530-385574 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On 2021-12-17 13:46:53 [-0500], Waiman Long wrote: > > annotation. Looking at the history, I'm also impressed by that fact that > > disabling/ enabling interrupts is *so* expensive that all this is > > actually worth it. > > For !RT with voluntary or no preemption, preempt_disable() is just a > compiler barrier. So it is definitely cheaper than disabling interrupt. The > performance benefit is less with preemptible but !RT kernel. Microbenchmark > testing shows a performance improvement of a few percents depending on the > exact benchmark. Thanks for confirming. I got the feeling that this optimisation is for !CONFIG_PREEMPTION. So I instead of depending on CONFIG_PREEMPT_RT I'm leaning towards CONFIG_PREEMPT instead. > Cheers, > Longman Sebastian