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 5343CC25B75 for ; Mon, 20 May 2024 02:15:19 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id B20186B0082; Sun, 19 May 2024 22:15:18 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id AA7F66B0083; Sun, 19 May 2024 22:15:18 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 921326B0085; Sun, 19 May 2024 22:15:18 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 70D296B0082 for ; Sun, 19 May 2024 22:15:18 -0400 (EDT) Received: from smtpin22.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id D7A8EC0AAB for ; Mon, 20 May 2024 02:15:17 +0000 (UTC) X-FDA: 82137157074.22.B95861A Received: from mail-vs1-f43.google.com (mail-vs1-f43.google.com [209.85.217.43]) by imf10.hostedemail.com (Postfix) with ESMTP id 485EEC0017 for ; Mon, 20 May 2024 02:15:16 +0000 (UTC) Authentication-Results: imf10.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=LfNi5jyk; spf=pass (imf10.hostedemail.com: domain of laoar.shao@gmail.com designates 209.85.217.43 as permitted sender) smtp.mailfrom=laoar.shao@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1716171316; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=ItY3dJ6r9GRDoSvMq3ooAXzy/Y3jWDpnBdowlwHmSnc=; b=itVLSyz+/8+RQqnCCYl7REGFWFD1bplWzPgfCSLbyFrm+VGNrELdZtcnnzB6tpfckbY8cA nN3HnEhGcae60uiyiix0+p2JztP4I6kcrM0OuriYWGCUnssxbpbMSpo60GKK1SgI4RP+lc Be+iWOG+76mfaYR7GIBr245QDaSIUFg= ARC-Authentication-Results: i=1; imf10.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=LfNi5jyk; spf=pass (imf10.hostedemail.com: domain of laoar.shao@gmail.com designates 209.85.217.43 as permitted sender) smtp.mailfrom=laoar.shao@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1716171316; a=rsa-sha256; cv=none; b=hWb7r9KOU9DQvykXd0r+73RJl4QLcaM70SvqEGyrmaeR4uwowxPWnvu4x5/WmwRt25TpIa CPmkfEg8HtqQM7pMjcOeX4oUuBsxpyTKdvSwnyt7CGqYDbZnaMIb2P9dYumI3fXOu2z7PN lE+ng8xas79IBJ0lM0Q8UayJpSR6+go= Received: by mail-vs1-f43.google.com with SMTP id ada2fe7eead31-47f01a027easo300721137.0 for ; Sun, 19 May 2024 19:15:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1716171315; x=1716776115; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=ItY3dJ6r9GRDoSvMq3ooAXzy/Y3jWDpnBdowlwHmSnc=; b=LfNi5jyk3/J9eBJZ36X7ncE0+Ag3D/QpoWPs8AtQc8t2xeeNKTXtSTb/2wMbM4iWgI KGY9PhCOIJpvClGiL694e1DSr0KZCEs+Rfyq0eHIzqRkQARyMMqA22bv4HYZYmxnnm4p /WwxNmMqF5Rp6INwG7JzMw2bhl06sQ0jArURigYasajvKCXy2N4AeDD/GQ+JmNBc4iAu n1Y6sRTSxvfZTdYMEsiR3lhE0yGzLsFKjKYk9O52ki5Eab5B8eGB4W/is8vhHpxMJM8T Lbn9Qc7a+mbsCA38gGgQOGJiM5Jxv5DBuv488vRI8HM+55zMuvAw4/96hN1xV/vP7ww3 RhHA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1716171315; x=1716776115; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=ItY3dJ6r9GRDoSvMq3ooAXzy/Y3jWDpnBdowlwHmSnc=; b=meVXtkMuNHKJlTVxihUuJ8pBljUu4ByBcvmHQvDoG4dnxMvYrxZHrPZ/vZo6KnnIaE UFu4lpVsOM0De47A9JVA9fTbAf0fznt6pvbJmD267bfrIE2oq8YdYKReYNPVYvPalsPj cYXd6bu0QtjREC4+OUBOFPPhmaI4g4yDix1AlbvPdJtQfz9cVEQHP56AtU4OOqT/hxWJ QGWG/v7MAaqhaJ0rZ53xT7xCf2VAuOKiB8t4AZ6sQUmcECAqQhCEBpNlAuuxkRfH3zqb vaWuZUnXlJR+lgpZ4GLXb7c02Vzi3Tz17OgSxgqcGB/HLQ7xQU+ioYHyxMgF5I4KcHDZ pxSw== X-Forwarded-Encrypted: i=1; AJvYcCXA0K8VoaK4AIutqC3ihw7ov6KnLL+nCJPZ8KRFLwNIC0Mn51Z0EPNKPDrm4ziREYui6NPrnboQuHQSn5QFN3eu/YI= X-Gm-Message-State: AOJu0YyzFxuGgiCLrkIWhB0kjqmcfmI86xc6gf7+axCcRNFzQwx7Ohlc YWWM48xpKWlfaZT15HMsVuZ7jozfz/9lSZJeUu0Isbx38zpdkEoZE2MskcrVl4n8Y7UjTuxu166 W4bT0BTGEC1sdY40rzCVH/6DRncg= X-Google-Smtp-Source: AGHT+IHLIiOr6c/yXHrwB0GZnzQC+NRw3mkL9lwRS6pyms1Fy2BtK39c6kFtX63WC4ag0icy6HIRNhmQLnROLyrLeAk= X-Received: by 2002:a05:6102:418d:b0:47b:ca6a:c5d9 with SMTP id ada2fe7eead31-48077e8122amr22895009137.28.1716171313827; Sun, 19 May 2024 19:15:13 -0700 (PDT) MIME-Version: 1.0 References: <20240509034138.2207186-1-roman.gushchin@linux.dev> In-Reply-To: From: Yafang Shao Date: Mon, 20 May 2024 10:14:36 +0800 Message-ID: Subject: Re: [PATCH rfc 0/9] mm: memcg: separate legacy cgroup v1 code and put under config option To: Shakeel Butt Cc: Yosry Ahmed , Roman Gushchin , Andrew Morton , Muchun Song , Johannes Weiner , Michal Hocko , Matthew Wilcox , linux-mm@kvack.org, linux-kernel@vger.kernel.org, gthelen@google.com, rientjes@google.com, Chris Li , Ivan Babrou Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Rspamd-Server: rspam09 X-Rspamd-Queue-Id: 485EEC0017 X-Stat-Signature: h9o6kuz95es1yueroihnqiixztg5qr5p X-HE-Tag: 1716171316-668082 X-HE-Meta: U2FsdGVkX18ho97BbKKLy/R95NEzfXLLzx9hAzzlB/wag94C+hr1HxINadxvgPrIUg/ztjZka2USeh3XAUvoA/P+ISLDKorXVKWzuko/DvxJnVz/aJ4BiKJL5T6HmWw2/P9WFsXSu+j1wKZYkT491EEynaqXJg0+t8rNG2uwRNZBpRVzSRhWeYGbUUNiSX0RR/SClv4FhbG1m60PVFXRfFKga1ubBwz6aevNfJTQKzRL45ud2RBa8CIRMDI9ajuCvq/zwuaPztELzrGP4SsBBDfpb3qDD5rb/m8lrfjdMRKbhM5KhZOECCy9a2dcdh75+ax0hQQPpkcOBl3uWbOHrreQDtFAS6L8X/R786zd2Rpw1ZvrqyO542hJjeG/vbI9zsJNx0XeMzDa0wTH2xSPX+1sDYFc8BnMZ0lLNymW0myi0EFmeoSNESu4zUoIuxCO+POfwuDqh4L2WqUhobhE+wDGv24LjNlMDG6Ar0Bydtg+cNRBO9t8m5WZKxXA11UBwVDxMBj9v1pbgIL7FG22CQWpweb0mnb6uAu/6oEsocnTSSlmLFh9NlQGv6/Bd8dXrEdlYnKVViAFVqRNGIXuhTEQ9NO6rj2jnFH4S05n1fxyHwDAr6fTmorC18TTjCzSA1Tk5nyR9+Ku5TzcsXUd8GnQohTidwYRppfHAuDDUHTv9MuzNqd/mHV5Go9ZOtIKk7Do5zl0dHVPRvon10zt8hsga3ZSd3K2L0KQFvV16qwWIb6jTuISQStw6DjKHFITAfcX3SCPHFZ5J6yn/oJkoBalPyDhkzBFI2CSUf6uCgtVzfQGe0f0uLQvYAgKivTheldaO2vVBWAWSFG6E7j0NR2h80dnpHXkHNEzPbTz+zd/5B0wfvJvcfZ4NyywJ+4ok/PIqiZ12F4B/I2HmxjGeSZS2rEt0fhSIAqnSvczq0JG83N+vNqCencb/wGxgrvc4o8FGJtIVy02TuRAqg/ GoQTXnTy CyFXF62aNWBZ8PHyg5yckci0BliBA3CUEzNqX9kGf0wkxWSkmHJw6rq7HHhlHXEeM0dZs X-Bogosity: Ham, tests=bogofilter, spamicity=0.000053, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Sat, May 18, 2024 at 3:33=E2=80=AFPM Shakeel Butt wrote: > > On Thu, May 16, 2024 at 11:35:57AM +0800, Yafang Shao wrote: > > On Thu, May 9, 2024 at 2:33=E2=80=AFPM Shakeel Butt wrote: > > > > > > [...] > > Hi Shakeel, > > > > Hopefully I'm not too late. We are currently using memcg v1. > > > > One specific feature we rely on in v1 is skmem accounting. In v1, we > > account for TCP memory usage without charging it to memcg v1, which is > > useful for monitoring the TCP memory usage generated by tasks running > > in a container. However, in memcg v2, monitoring TCP memory requires > > charging it to the container, which can easily cause OOM issues. It > > would be better if we could monitor skmem usage without charging it in > > the memcg v2, allowing us to account for it without the risk of > > triggering OOM conditions. > > > > Hi Yafang, > > No worries. From what I understand, you are not really using skmem > charging of v1 but just the network memory usage stats and you are > worried that charging network memory to cgroup memory may cause OOMs. Is > that correct? Correct. > Have you tried charging network memory to cgroup memory > before and saw OOMs? If yes then I would really like to see OOM reports. No, we don't enable the charging for TCP memory in memcg v1 and we don't have a plan to add support for it currently. > > I have two examples where the v2's skmem charging is working fine in > production namely Google and Meta. Google is still on v1 but for skmem > charging, they have moved to v2 semantics. Actually I have another > report from Cloudflare [0] where the tcp throttling mechanism for v2's > tcp memory accounting is too much conservative for their production > traffic. > > Anyways this just means that we need a more flexible way to provide > and enforce semantics for tcp memory pressure with a decent default > behavior. I will followup on this separately. > > [0] https://lore.kernel.org/lkml/CABWYdi0G7cyNFbndM-ELTDAR3x4Ngm0AehEp5aP= 0tfNkXUE+Uw@mail.gmail.com/ Thanks for your explanation. --=20 Regards Yafang