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 34A41C05027 for ; Wed, 1 Feb 2023 12:41:22 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A75106B0071; Wed, 1 Feb 2023 07:41:21 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id A23696B0072; Wed, 1 Feb 2023 07:41:21 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8EBE96B0074; Wed, 1 Feb 2023 07:41:21 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 7C9B46B0071 for ; Wed, 1 Feb 2023 07:41:21 -0500 (EST) Received: from smtpin21.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 5885080CF2 for ; Wed, 1 Feb 2023 12:41:21 +0000 (UTC) X-FDA: 80418683562.21.CDE0F3A Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.220.28]) by imf04.hostedemail.com (Postfix) with ESMTP id 4F9A44001F for ; Wed, 1 Feb 2023 12:41:19 +0000 (UTC) Authentication-Results: imf04.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b="MWzo9/68"; dmarc=pass (policy=quarantine) header.from=suse.com; spf=pass (imf04.hostedemail.com: domain of mhocko@suse.com designates 195.135.220.28 as permitted sender) smtp.mailfrom=mhocko@suse.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1675255279; 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-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=pgarzvo5Cio7GL8GEMMFzzwnzoa+QoIct7DEsSsHtqA=; b=RWqDdeokXC6MfGmTnfujf9WuDHq2tzFZhYDepbXR2pZeska7OCyAtdkgDJSehIHZaXepdz WDK0E7GvxHbWRzF5vp//5xj3TIr3cnOh8RchUjFaeUNPiIWI+1dTttZ6RtbaW10DgKK8FR Wn2e7UNOUiHA1QRGvjhWUemt1BuiQbI= ARC-Authentication-Results: i=1; imf04.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b="MWzo9/68"; dmarc=pass (policy=quarantine) header.from=suse.com; spf=pass (imf04.hostedemail.com: domain of mhocko@suse.com designates 195.135.220.28 as permitted sender) smtp.mailfrom=mhocko@suse.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1675255279; a=rsa-sha256; cv=none; b=MsoB/+RL/EKN8pu3zd8X5X4ecC57Av45ADhS8C4BSj0OTGObZwXxmv0E9Sp0G223Tw9OG9 fZCqwr1GkwoUgVFfotHc4pOQlQxDx6sYl+1on4pGqjcORZOteAIdkuYTvAddvNk06OxM4D XRJyX+wNuvOfueP5IZOVxTqzP3FkICw= Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by smtp-out1.suse.de (Postfix) with ESMTPS id 9E81B33D30; Wed, 1 Feb 2023 12:41:17 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1675255277; h=from:from:reply-to: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=pgarzvo5Cio7GL8GEMMFzzwnzoa+QoIct7DEsSsHtqA=; b=MWzo9/68aPfyUUKt0sBZONEVCQnB5Rnc7js3asZl1hGklDyD/kUD3l3yb52I05gyiwCGwJ FkltqazCB0qBi1IKYo4fWm7hphLeefGDPXjfrTgp8Qe/444/6AfB68SNhBTUfZhen1TiXu 2Go0U87UliFst4DLvBn7AcwTkPETxhg= Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by imap2.suse-dmz.suse.de (Postfix) with ESMTPS id 7CAF51348C; Wed, 1 Feb 2023 12:41:17 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id T9EqHO1d2mMjQQAAMHmgww (envelope-from ); Wed, 01 Feb 2023 12:41:17 +0000 Date: Wed, 1 Feb 2023 13:41:16 +0100 From: Michal Hocko To: Marcelo Tosatti Cc: Leonardo =?iso-8859-1?Q?Br=E1s?= , Johannes Weiner , Roman Gushchin , Shakeel Butt , Muchun Song , Andrew Morton , cgroups@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v2 0/5] Introduce memcg_stock_pcp remote draining Message-ID: References: <20230125073502.743446-1-leobras@redhat.com> <9e61ab53e1419a144f774b95230b789244895424.camel@redhat.com> <0122005439ffb7895efda7a1a67992cbe41392fe.camel@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspam-User: X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: 4F9A44001F X-Stat-Signature: ze448t3mng6mk3nqoqjrfbm4j1g6nixg X-HE-Tag: 1675255279-715383 X-HE-Meta: U2FsdGVkX18x23kWiCikk/YOLT2f6mFexp2THeOF2g76k+ifp8olFLE1zUMh/20UQTMmy1M8+G+PW9WYXWmlu4qfFB7s97aBVkZPVXQeY5d7ouZteJFPNNly0QKou8lb/UAtVySrwhISj3bBrA0jgZr3Q+NGCPeqoz4fzAra0ovPiPcTC+MbtMdgvqGERFH0zzm/EDy8ZAyDZ/DlE7th1lTpK0gM7WssIZigeJvKoVEANbGYtydQ66Qo4em/lWScEvSC4OXLll5fpAeYe4MQRopqhH2u3+DOHQ9+o2kNvSJ0uM/qMo/E1O8AYiLwtnIbvPRW/70rOs94mfYyhPX3HOlmcpxdcZFgEib0R2YIcf2GTxICjFL22McGNmju3e/WbK6L1dnVgtzetV2EkraDQEprTpI42t9chhUjDPYGcclM9Jwsl6OOwTaD/gjSzRpviiK2oxxp8kHJm1uNMkvDrOg1Mru0dipsrrUxYcTjLzCVWelixOttsLPbwrUKLCihBdDMn7IQ+uewCV5LhnTqC1qPu97QeH1Wc+w1gDnLiyYBPOHJURtWMS1QT8/PDSz/AQpW/lea//jeOYdh3lp+q9uO4BlTgbSG6Wj0Sw35lIeIhglWKj1Tej5JBO5oZfV9EHS/4PyvchV5u5oBXYiVwA3hvWlXToTqELE+gFqKKl4RDzpIrLc+d7H1jhmqvvogE59eJDtAOUsj4V4GVyNU1Y1n5jsLJKfVJbZj1o7i6+9bvWP6YwYJq3PcOJkSOsvLAOemTFNt8xYzVMUQPGIUo/sKU4svC9x8tAs/HNVH7zi8JPtjwc3Tm1o82MaYchJt3gK8qHPM6sVJHBZoe3TpxwLhi7Qmjm7VKJWHPyW5+bmj1aan2zOybes1IU2DfVZTguyHkSzdrFgWIdhwYzWYbKbdboj5o0gGEndMZb/6gUQa9LoZ2CNCEZZpWjkK6g8kOX8cTb0XR3Gu7VsruJ3 VSCcgAdd vMTTnk8711IuQjStic3DauxLijXh0+JR/QWDJuy5JGCisANcE78zN4FBTGabWEEh1jaZhuMD3MggYr4o95Y3SPrLK2ZNkPOBNUHQRBS7JRu7egbpT0hOlE4UCzKSxAz3lqlLtjNSlS+bmDSlsav4MerOC+u0+MDp8g0rR6GZNjC+1aQss9/VnRD5IxG8XIUrqV5NnLk7uGW3jc5IEWsciRct8cQ== 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 Tue 31-01-23 08:35:34, Marcelo Tosatti wrote: [...] > So it would be good to point out a specific problematic > testcase/scenario with using the spinlock in this particular case? Please think about it some more. The sole purpose of the pcp charge caching is to avoid atomics because the normal fast path (i.e. no limit hit) is a page counter which is an atomic counter. If you go with a spin lock for the pcp cache you are just losing some of the advantage of the caching. Sure that would be a smaller atomics use than a deeper memcg hierarchy but still. Not to mention a potential contention which is hard to predict and it will depend on the specific runtime very much. So not something that would be easy to test for other than artificial testcases. Full cpu pcp draining is not a very common operation and one could argue that the problem will be limited but so far I haven't really heard any strong arguments against the proposal to avoid scheduling the work on isolated cpus which is a much more simpler solution and achieves the same effect. -- Michal Hocko SUSE Labs