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 4228AC43334 for ; Thu, 7 Jul 2022 07:47:20 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 42DB06B0072; Thu, 7 Jul 2022 03:47:19 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 3DD9D6B0073; Thu, 7 Jul 2022 03:47:19 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2CC0D6B0074; Thu, 7 Jul 2022 03:47:19 -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 1D5DD6B0072 for ; Thu, 7 Jul 2022 03:47:19 -0400 (EDT) Received: from smtpin28.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay12.hostedemail.com (Postfix) with ESMTP id E03DF120CE5 for ; Thu, 7 Jul 2022 07:47:18 +0000 (UTC) X-FDA: 79659523356.28.538A1EA Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.220.29]) by imf05.hostedemail.com (Postfix) with ESMTP id 5DF24100019 for ; Thu, 7 Jul 2022 07:47:18 +0000 (UTC) Received: from relay2.suse.de (relay2.suse.de [149.44.160.134]) by smtp-out2.suse.de (Postfix) with ESMTP id C03C01FA93; Thu, 7 Jul 2022 07:47:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1657180036; 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=CEd2Na7ZICW0cPoFXBq3xNRf0e9K1vxcQxK9+w/pQcI=; b=hCVarrs4y/FY6SmlaBkGnrAWX3Sk5hubEwYhKsTJb62VdDHL+aJngsV0bEiPEOfhy/YYhV oBReVvZuCQeBjWbP7T6ZvocSNnsTZzkkRNq3CQvD4pqTp/MXqTc9q9Xe7CHeSDWm44VhDR 5aGIVC7go5KC9Z14yDAq0U1DJsFK+E4= Received: from suse.cz (unknown [10.100.201.86]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by relay2.suse.de (Postfix) with ESMTPS id 48B112C141; Thu, 7 Jul 2022 07:47:16 +0000 (UTC) Date: Thu, 7 Jul 2022 09:47:16 +0200 From: Michal Hocko To: Yafang Shao Cc: Roman Gushchin , Shakeel Butt , Andrew Morton , Johannes Weiner , Muchun Song , Cgroups , Linux MM , bpf Subject: Re: [PATCH] mm: memcontrol: do not miss MEMCG_MAX events for enforced allocations Message-ID: References: <20220702033521.64630-1-roman.gushchin@linux.dev> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1657180038; a=rsa-sha256; cv=none; b=UeF9S4qOxqhf7SHDZedOJ5+KCUwZXsnsVPTrmJknhqFgf+fbc/WefRUDRveAkYCGl08+9v y+Dxhu66WGbbvUyqWr3LYW7XB4xZvT/1UMRdAVkK1woChpCtuwb1DUSL5hrhZF+f2k+zqh JJBZOoi+5XNddJiTYQgTkR4ngp7ggUQ= ARC-Authentication-Results: i=1; imf05.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b=hCVarrs4; spf=pass (imf05.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-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1657180038; 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=CEd2Na7ZICW0cPoFXBq3xNRf0e9K1vxcQxK9+w/pQcI=; b=xU9L6ZfGUEoStqx8VJ6YSqOZH/IGTY1ou5ke1uWWtOAebq7es0mlqbSAicNuDjtcKRN7Rq zcvaqgzLgDwmbPAYbfeHIKCIIDBJ15zdx9FTUAP52ZhwwD+/kImSXYpYq9ZoTwh8yMAVEo X8IsofmVGqMR9ddzs0XnWC31bBlxv4c= X-Rspamd-Server: rspam09 X-Rspamd-Queue-Id: 5DF24100019 X-Rspam-User: Authentication-Results: imf05.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b=hCVarrs4; spf=pass (imf05.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-Stat-Signature: 33y99d4u3wppj5ugndmnfp49qczyatmr X-HE-Tag: 1657180038-809821 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 Wed 06-07-22 10:40:48, Yafang Shao wrote: > On Wed, Jul 6, 2022 at 4:52 AM Roman Gushchin wrote: > > > > On Mon, Jul 04, 2022 at 05:30:25PM +0200, Michal Hocko wrote: > > > On Mon 04-07-22 17:07:32, Michal Hocko wrote: > > > > On Sat 02-07-22 08:39:14, Roman Gushchin wrote: > > > > > On Fri, Jul 01, 2022 at 10:50:40PM -0700, Shakeel Butt wrote: > > > > > > On Fri, Jul 1, 2022 at 8:35 PM Roman Gushchin wrote: > > > > > > > > > > > > > > Yafang Shao reported an issue related to the accounting of bpf > > > > > > > memory: if a bpf map is charged indirectly for memory consumed > > > > > > > from an interrupt context and allocations are enforced, MEMCG_MAX > > > > > > > events are not raised. > > > > > > > > > > > > > > It's not/less of an issue in a generic case because consequent > > > > > > > allocations from a process context will trigger the reclaim and > > > > > > > MEMCG_MAX events. However a bpf map can belong to a dying/abandoned > > > > > > > memory cgroup, so it might never happen. > > > > > > > > > > > > The patch looks good but the above sentence is confusing. What might > > > > > > never happen? Reclaim or MAX event on dying memcg? > > > > > > > > > > Direct reclaim and MAX events. I agree it might be not clear without > > > > > looking into the code. How about something like this? > > > > > > > > > > "It's not/less of an issue in a generic case because consequent > > > > > allocations from a process context will trigger the direct reclaim > > > > > and MEMCG_MAX events will be raised. However a bpf map can belong > > > > > to a dying/abandoned memory cgroup, so there will be no allocations > > > > > from a process context and no MEMCG_MAX events will be triggered." > > > > > > > > Could you expand little bit more on the situation? Can those charges to > > > > offline memcg happen indefinetely? How can it ever go away then? Also is > > > > this something that we actually want to encourage? > > > > > > One more question. Mostly out of curiosity. How is userspace actually > > > acting on those events? Are watchers still active on those dead memcgs? > > > > Idk, the whole problem was reported by Yafang, so he probably has a better > > answer. But in general events are recursive and the cgroup doesn't have > > to be dying, it can be simple abandoned. > > > > Regarding the pinned bpf programs, it can run without a user agent. > That means the cgroup may not be dead, but just not populated. > (But in our case, the cgroup will be deleted after the user agent exits.) OK, that makes sense. -- Michal Hocko SUSE Labs