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 66C50C433F5 for ; Mon, 3 Jan 2022 14:44:49 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 817FF6B0072; Mon, 3 Jan 2022 09:44:48 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 7C6F46B0073; Mon, 3 Jan 2022 09:44:48 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 68F156B0074; Mon, 3 Jan 2022 09:44:48 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0208.hostedemail.com [216.40.44.208]) by kanga.kvack.org (Postfix) with ESMTP id 534126B0072 for ; Mon, 3 Jan 2022 09:44:48 -0500 (EST) Received: from smtpin18.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 0FF1591E28 for ; Mon, 3 Jan 2022 14:44:48 +0000 (UTC) X-FDA: 78989247456.18.2BE253F Received: from galois.linutronix.de (Galois.linutronix.de [193.142.43.55]) by imf29.hostedemail.com (Postfix) with ESMTP id 9257A12000B for ; Mon, 3 Jan 2022 14:44:40 +0000 (UTC) Date: Mon, 3 Jan 2022 15:44:43 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1641221085; 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=MMUvJRIkEcl/HJeYgUz7jPr4JCoO6K1Up59xnJmJgyk=; b=yGq7pCT9OQF2OULtqlUID71JjXUJRRIthcE3nLvs3IsuEMDmm7DKB6BwqR4feaD0QBdqJ6 9+CnBU37MXDi5u+P8dBMjQ52TujOG/k0wD6fJ9ty2CyVFJ0/t1H75r7XosdVhTDGQZyvDI PIwNhBd3XbVr1m43ohKrl2OgtoiaTnXryWDXwzpKEhsMrJtRn5hZv6iVSxgHhpflcddZe2 vYJ7lfVDp26v45pbMY8WxDdXzSFu+mBw0PqZ36lc1CQLixFDcsZTkpTBRO81wjAN7XxoUt tC4CshvqEhjxTRbAIWDjJGeEMrKSZVdzxXWT2z5klLBvclteEdxUQbx9CqLA+g== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1641221085; 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=MMUvJRIkEcl/HJeYgUz7jPr4JCoO6K1Up59xnJmJgyk=; b=hYVBfawsiIaUZryqk/cOnDY1U28vyW23NzoboozVAU01QeqNXSM4bL0gqFY70HduRTVSkY SAC66k1iOvK0NbCA== From: Sebastian Andrzej Siewior To: Waiman Long Cc: cgroups@vger.kernel.org, linux-mm@kvack.org, Johannes Weiner , Michal Hocko , Vladimir Davydov , Andrew Morton , Thomas Gleixner , Peter Zijlstra Subject: Re: [RFC PATCH 3/3] mm/memcg: Allow the task_obj optimization only on non-PREEMPTIBLE kernels. Message-ID: References: <20211222114111.2206248-1-bigeasy@linutronix.de> <20211222114111.2206248-4-bigeasy@linutronix.de> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: X-Rspamd-Server: rspam08 X-Rspamd-Queue-Id: 9257A12000B X-Stat-Signature: i7u33g5ftjzpbsqbrfccdshozkuwdb9a Authentication-Results: imf29.hostedemail.com; dkim=pass header.d=linutronix.de header.s=2020 header.b=yGq7pCT9; dkim=pass header.d=linutronix.de header.s=2020e header.b=hYVBfaws; spf=pass (imf29.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-HE-Tag: 1641221080-187681 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-23 16:48:41 [-0500], Waiman Long wrote: > On 12/22/21 06:41, Sebastian Andrzej Siewior wrote: > > Based on my understanding the optimisation with task_obj for in_task() > > mask sense on non-PREEMPTIBLE kernels because preempt_disable()/enable() > > is optimized away. This could be then restricted to !CONFIG_PREEMPTION kernel > > instead to only PREEMPT_RT. > > With CONFIG_PREEMPT_DYNAMIC a non-PREEMPTIBLE kernel can also be > > configured but these kernels always have preempt_disable()/enable() > > present so it probably makes no sense here for the optimisation. > > > > Restrict the optimisation to !CONFIG_PREEMPTION kernels. > > > > Signed-off-by: Sebastian Andrzej Siewior > > If PREEMPT_DYNAMIC is selected, PREEMPTION will also be set. My > understanding is that some distros are going to use PREEMPT_DYNAMIC, but > default to PREEMPT_VOLUNTARY. So I don't believe it is a good idea to > disable the optimization based on PREEMPTION alone. So there is a benefit to this even if preempt_disable() is not optimized away? My understanding was that this depends on preempt_disable() being optimized away. Is there something you recommend as a benchmark where I could get some numbers? > Regards, > Longman Sebastian