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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 850E2C636D3 for ; Wed, 1 Feb 2023 12:41:22 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231917AbjBAMlV (ORCPT ); Wed, 1 Feb 2023 07:41:21 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:52212 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229451AbjBAMlU (ORCPT ); Wed, 1 Feb 2023 07:41:20 -0500 Received: from smtp-out1.suse.de (smtp-out1.suse.de [IPv6:2001:67c:2178:6::1c]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id EEC8FCC; Wed, 1 Feb 2023 04:41:18 -0800 (PST) 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: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michal Hocko Subject: Re: [PATCH v2 0/5] Introduce memcg_stock_pcp remote draining Date: Wed, 1 Feb 2023 13:41:16 +0100 Message-ID: References: <20230125073502.743446-1-leobras@redhat.com> <9e61ab53e1419a144f774b95230b789244895424.camel@redhat.com> <0122005439ffb7895efda7a1a67992cbe41392fe.camel@redhat.com> Mime-Version: 1.0 Return-path: 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= Content-Disposition: inline In-Reply-To: List-ID: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Marcelo Tosatti Cc: Leonardo =?iso-8859-1?Q?Br=E1s?= , Johannes Weiner , Roman Gushchin , Shakeel Butt , Muchun Song , Andrew Morton , cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org, linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org 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