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 5699BC433EF for ; Thu, 13 Jan 2022 15:26:59 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 9EE746B0072; Thu, 13 Jan 2022 10:26:58 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 99E916B0073; Thu, 13 Jan 2022 10:26:58 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 866336B0074; Thu, 13 Jan 2022 10:26:58 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0248.hostedemail.com [216.40.44.248]) by kanga.kvack.org (Postfix) with ESMTP id 79F296B0072 for ; Thu, 13 Jan 2022 10:26:58 -0500 (EST) Received: from smtpin26.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 30B0F8C5B2 for ; Thu, 13 Jan 2022 15:26:58 +0000 (UTC) X-FDA: 79025641674.26.0F62045 Received: from galois.linutronix.de (Galois.linutronix.de [193.142.43.55]) by imf18.hostedemail.com (Postfix) with ESMTP id 81D9E1C0008 for ; Thu, 13 Jan 2022 15:26:57 +0000 (UTC) Date: Thu, 13 Jan 2022 16:26:53 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1642087615; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=3PME2FpL39l8UfdTGdt/K8iiXCT0iRe1U4l/qKjasvE=; b=xyYobnza+rb0w299CIUfcT/8YSuAWX8YPSXQp3auduyovbXL8q+0gDqfU0egc539YdIIHN HmZ9rSmXHTfbSOIxtojfout368SBx8GEiR8LW7reD6QgcjqgppdzEW0yktcI6b7PN/S6y7 ibrSA9eIvw3uCkFMJtbRQ0JTh/cDBUijsGjTSbVbsHqVi31OmOcF4+PmJVUv22RTZ69Vnp A9HplElzCOx0in20rwUsz9AQdyNW0JekuI+c556EQJWy+H92Qaib8jYN7i4lWoPQDp3IU7 REOvCYncjQjCw0y36eo77a24hUYomATr0n6eH2f4cKsvfzbXlIYxMCYkGUowEQ== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1642087615; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=3PME2FpL39l8UfdTGdt/K8iiXCT0iRe1U4l/qKjasvE=; b=cEVxRwtThmIYCDbZjpCk1IC2I9dmoi9VxWBYoVhlo0M0NRHU0M/iRll8vIGuk+mYBn4TKd BYyqMdwuwJxavUCQ== 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> <29457251-cf4f-4c7d-b36d-c2a0af4da707@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: <29457251-cf4f-4c7d-b36d-c2a0af4da707@redhat.com> Authentication-Results: imf18.hostedemail.com; dkim=pass header.d=linutronix.de header.s=2020 header.b=xyYobnza; dkim=pass header.d=linutronix.de header.s=2020e header.b=cEVxRwtT; dmarc=pass (policy=none) header.from=linutronix.de; spf=pass (imf18.hostedemail.com: domain of bigeasy@linutronix.de designates 193.142.43.55 as permitted sender) smtp.mailfrom=bigeasy@linutronix.de X-Stat-Signature: 7hri8ctnqmkq77gceckd3u1kh9u79au5 X-Rspamd-Queue-Id: 81D9E1C0008 X-Rspamd-Server: rspam12 X-HE-Tag: 1642087617-151157 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 2022-01-05 22:28:10 [-0500], Waiman Long wrote: > Thanks for the extensive testing. I usually perform my performance test on > Intel hardware. I don't realize that Zen2 and arm64 perform better with i= rq > on/off. Maybe you have access to more recent =C2=B5Arch from Intel which could beha= ve different. > My own testing when tracking the number of times in_task() is true or fal= se > indicated most of the kmalloc() call is done by tasks. Only a few percents > of the time is in_task() false. That is the reason why I optimize the case > that in_task() is true. Right. This relies on the fact that changing preemption is cheaper which is not always true. The ultimate benefit is of course when the preemption changes can be removed/ optimized away. > > Based on that, I don't see any added value by the optimisation once > > PREEMPT_DYNAMIC is enabled. >=20 > The PREEMPT_DYNAMIC result is a bit surprising to me. Given the data poin= ts, > I am not going to object to this patch then. I will try to look further i= nto > why this is the case when I have time. Okay, thank you. In the SERVER case we keep the preemption counter so this has obviously an impact. I am a little surprised that the DYN-FULL and DYN-NONE differ a little since the code runs with disabled interrupts. But then this might be the extra jump to preempt_schedule() which is patched-out in the SERVER case. > Cheers, > Longman Sebastian From mboxrd@z Thu Jan 1 00:00:00 1970 From: Sebastian Andrzej Siewior Subject: Re: [RFC PATCH 3/3] mm/memcg: Allow the task_obj optimization only on non-PREEMPTIBLE kernels. Date: Thu, 13 Jan 2022 16:26:53 +0100 Message-ID: References: <20211222114111.2206248-1-bigeasy@linutronix.de> <20211222114111.2206248-4-bigeasy@linutronix.de> <29457251-cf4f-4c7d-b36d-c2a0af4da707@redhat.com> Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Return-path: DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1642087615; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=3PME2FpL39l8UfdTGdt/K8iiXCT0iRe1U4l/qKjasvE=; b=xyYobnza+rb0w299CIUfcT/8YSuAWX8YPSXQp3auduyovbXL8q+0gDqfU0egc539YdIIHN HmZ9rSmXHTfbSOIxtojfout368SBx8GEiR8LW7reD6QgcjqgppdzEW0yktcI6b7PN/S6y7 ibrSA9eIvw3uCkFMJtbRQ0JTh/cDBUijsGjTSbVbsHqVi31OmOcF4+PmJVUv22RTZ69Vnp A9HplElzCOx0in20rwUsz9AQdyNW0JekuI+c556EQJWy+H92Qaib8jYN7i4lWoPQDp3IU7 REOvCYncjQjCw0y36eo77a24hUYomATr0n6eH2f4cKsvfzbXlIYxMCYkGUowEQ== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1642087615; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=3PME2FpL39l8UfdTGdt/K8iiXCT0iRe1U4l/qKjasvE=; b=cEVxRwtThmIYCDbZjpCk1IC2I9dmoi9VxWBYoVhlo0M0NRHU0M/iRll8vIGuk+mYBn4TKd BYyqMdwuwJxavUCQ== Content-Disposition: inline In-Reply-To: <29457251-cf4f-4c7d-b36d-c2a0af4da707-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> List-ID: Content-Type: text/plain; charset="iso-8859-9" To: Waiman Long Cc: cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org, Johannes Weiner , Michal Hocko , Vladimir Davydov , Andrew Morton , Thomas Gleixner , Peter Zijlstra On 2022-01-05 22:28:10 [-0500], Waiman Long wrote: > Thanks for the extensive testing. I usually perform my performance test on > Intel hardware. I don't realize that Zen2 and arm64 perform better with i= rq > on/off. Maybe you have access to more recent =C2=B5Arch from Intel which could beha= ve different. > My own testing when tracking the number of times in_task() is true or fal= se > indicated most of the kmalloc() call is done by tasks. Only a few percents > of the time is in_task() false. That is the reason why I optimize the case > that in_task() is true. Right. This relies on the fact that changing preemption is cheaper which is not always true. The ultimate benefit is of course when the preemption changes can be removed/ optimized away. > > Based on that, I don't see any added value by the optimisation once > > PREEMPT_DYNAMIC is enabled. >=20 > The PREEMPT_DYNAMIC result is a bit surprising to me. Given the data poin= ts, > I am not going to object to this patch then. I will try to look further i= nto > why this is the case when I have time. Okay, thank you. In the SERVER case we keep the preemption counter so this has obviously an impact. I am a little surprised that the DYN-FULL and DYN-NONE differ a little since the code runs with disabled interrupts. But then this might be the extra jump to preempt_schedule() which is patched-out in the SERVER case. > Cheers, > Longman Sebastian