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 C991CC25B08 for ; Tue, 23 Aug 2022 04:49:43 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id D55CB6B0073; Tue, 23 Aug 2022 00:49:42 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id D05DE6B0074; Tue, 23 Aug 2022 00:49:42 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id BCCCD8D0001; Tue, 23 Aug 2022 00:49:42 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id AAF786B0073 for ; Tue, 23 Aug 2022 00:49:42 -0400 (EDT) Received: from smtpin29.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 6F1FF81411 for ; Tue, 23 Aug 2022 04:49:42 +0000 (UTC) X-FDA: 79829629404.29.CF318E5 Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.220.29]) by imf20.hostedemail.com (Postfix) with ESMTP id E05D11C000B for ; Tue, 23 Aug 2022 04:49:41 +0000 (UTC) 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-out2.suse.de (Postfix) with ESMTPS id 4ED8320C08; Tue, 23 Aug 2022 04:49:40 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1661230180; 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=6PhQCQsVbk7n5tc8kIa2TGPQzQV7xBjFKyKTp3F/kUQ=; b=GHdIKuo9daTXmA1UtzVKXzG3TkVRWU/Hmqj+RbiMv3OJ4dTblT04XZHLZp0aD5LS5cC30D 3LyVtaJ66+nfDToneuanA/XfjkqmCEmv+bcfxqmGjVPUhTTIduFHwku/BIQVPxPYqAn9vZ a1w9xWSCxG8vZkzqtnDB7CJ18m5DIb8= 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 2F49E13AB7; Tue, 23 Aug 2022 04:49:40 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id PzY0CWRcBGPBCgAAMHmgww (envelope-from ); Tue, 23 Aug 2022 04:49:40 +0000 Date: Tue, 23 Aug 2022 06:49:39 +0200 From: Michal Hocko To: Roman Gushchin Cc: Shakeel Butt , Johannes Weiner , Muchun Song , Michal =?iso-8859-1?Q?Koutn=FD?= , Eric Dumazet , Soheil Hassas Yeganeh , Feng Tang , Oliver Sang , Andrew Morton , lkp@lists.01.org, cgroups@vger.kernel.org, linux-mm@kvack.org, netdev@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 3/3] memcg: increase MEMCG_CHARGE_BATCH to 64 Message-ID: References: <20220822001737.4120417-1-shakeelb@google.com> <20220822001737.4120417-4-shakeelb@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1661230182; 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=6PhQCQsVbk7n5tc8kIa2TGPQzQV7xBjFKyKTp3F/kUQ=; b=SvoN4zs9OtV+nV8o1BmUsbLh3+dmy0ycOWzOgBWyGlm150riTmuOtvopI0I39IGmnfzAd7 S1gX9glBTCLzwfBflSLAnr4xDOSm7Ou5jSPBz7ajsb+65neKyz1ju0NGPJFUVS71xHObFl geaarvYFoVYLCX7GeYXMm4QPlUNS0kk= ARC-Authentication-Results: i=1; imf20.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b=GHdIKuo9; spf=pass (imf20.hostedemail.com: domain of mhocko@suse.com designates 195.135.220.29 as permitted sender) smtp.mailfrom=mhocko@suse.com; dmarc=pass (policy=quarantine) header.from=suse.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1661230182; a=rsa-sha256; cv=none; b=JQCJQArEIXMMZtAtFe+OnbtOwU4LyKeJgv7sReLgfVmx3L0zhe8mKKYPGqlZoA6h9AM/CB e883WrxpYPWx5+oeBkAA/qyF6ejBJ2G1HhZB96v0AR5hRsUNrSeP6S8rPYXIyFIdm6F7NI UZN0BSegMqoe/IARyIChL0Biz24iraE= X-Rspamd-Queue-Id: E05D11C000B X-Rspam-User: Authentication-Results: imf20.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b=GHdIKuo9; spf=pass (imf20.hostedemail.com: domain of mhocko@suse.com designates 195.135.220.29 as permitted sender) smtp.mailfrom=mhocko@suse.com; dmarc=pass (policy=quarantine) header.from=suse.com X-Rspamd-Server: rspam05 X-Stat-Signature: 7e6bjqsokpk4gi1gamjqbiorarchao9t X-HE-Tag: 1661230181-135079 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 Mon 22-08-22 19:22:26, Roman Gushchin wrote: > On Mon, Aug 22, 2022 at 09:34:59PM +0200, Michal Hocko wrote: > > On Mon 22-08-22 11:37:30, Roman Gushchin wrote: > > [...] > > > I wonder only if we want to make it configurable (Idk a sysctl or maybe > > > a config option) and close the topic. > > > > I do not think this is a good idea. We have other examples where we have > > outsourced internal tunning to the userspace and it has mostly proven > > impractical and long term more problematic than useful (e.g. > > lowmem_reserve_ratio, percpu_pagelist_high_fraction, swappiness just to > > name some that come to my mind). I have seen more often these to be used > > incorrectly than useful. > > A agree, not a strong opinion here. But I wonder if somebody will > complain on Shakeel's change because of the reduced accuracy. > I know some users are using memory cgroups to track the size of various > workloads (including relatively small) and 32->64 pages per cpu change > can be noticeable for them. But we can wait for an actual bug report :) Yes, that would be my approach. I have seen reports like that already but that was mostly because of heavy caching on the SLUB side on older kernels. So there surely are workloads with small limits configured (e.g. 20MB). On the other hand those users were receptive to adapt their limits as they were kinda arbitrary anyway. > > In this case, I guess we should consider either moving to per memcg > > charge batching and see whether the pcp overhead x memcg_count is worth > > that or some automagic tuning of the batch size depending on how > > effectively the batch is used. Certainly a lot of room for > > experimenting. > > I'm not a big believer into the automagic tuning here because it's a fundamental > trade-off of accuracy vs performance and various users might make a different > choice depending on their needs, not on the cpu count or something else. Yes, this not an easy thing to get right. I was mostly thinking some auto scaling based on the limit size or growing the stock if cache hits are common and decrease when stocks get flushed often because multiple memcgs compete over the same pcp stock. But to me it seems like a per memcg approach might lead better results without too many heuristics (albeit more memory hungry). > Per-memcg batching sounds interesting though. For example, we can likely > batch updates on leaf cgroups and have a single atomic update instead of > multiple most of the times. Or do you mean something different? No, that was exactly my thinking as well. -- Michal Hocko SUSE Labs