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 7328FCE7A81 for ; Mon, 25 Sep 2023 12:37:35 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 0DEE88D0025; Mon, 25 Sep 2023 08:37:35 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 08FB98D0001; Mon, 25 Sep 2023 08:37:35 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E99D98D0025; Mon, 25 Sep 2023 08:37:34 -0400 (EDT) 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 DC2DA8D0001 for ; Mon, 25 Sep 2023 08:37:34 -0400 (EDT) Received: from smtpin08.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id A7CD840576 for ; Mon, 25 Sep 2023 12:37:34 +0000 (UTC) X-FDA: 81275070828.08.6A4DF9C Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.220.29]) by imf11.hostedemail.com (Postfix) with ESMTP id A85EB40003 for ; Mon, 25 Sep 2023 12:37:32 +0000 (UTC) Authentication-Results: imf11.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b=bAXXeg+2; dmarc=pass (policy=quarantine) header.from=suse.com; spf=pass (imf11.hostedemail.com: domain of mhocko@suse.com designates 195.135.220.29 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=1695645453; 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=nLsSixWH3YAfP7MPArOkBvfmfGcgIYuoxbr0qN9YYMk=; b=QEzdOiDmGK0umN/YcqbHp+qwDNoHnd2G6In7is6RdmGil54Q1LfjhSa0qsGOJw/eCIaqQl 6qPG/W2sO2DOdFXaUJUE/ua4Lcc4crBHDVoaXq+nee8vwk6/OeSNINnJmoPhqcut25vGze TC/9oe1yoKKazhYngv66vWyxVF08n0Q= ARC-Authentication-Results: i=1; imf11.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b=bAXXeg+2; dmarc=pass (policy=quarantine) header.from=suse.com; spf=pass (imf11.hostedemail.com: domain of mhocko@suse.com designates 195.135.220.29 as permitted sender) smtp.mailfrom=mhocko@suse.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1695645453; a=rsa-sha256; cv=none; b=2sY+oYx2ano09YpfYdl8rmHyRaPBpJDqJGCtED7mumKY0PsyZ1d4GOAw0OVMhGD9K4RvhE gfNp3TWO7bKotGk+h4Bu2hvVHDljFhbyMIimmNJi7RUwHA+JbmP6VZYdiKtNFNT2rS5Xjv vOCPXLjpG2oD7ORBc+Q85meSjWBbRUo= 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 DDA191F45F; Mon, 25 Sep 2023 12:37:30 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1695645450; 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=nLsSixWH3YAfP7MPArOkBvfmfGcgIYuoxbr0qN9YYMk=; b=bAXXeg+2WDLQbdBQmXNyDeKlSvvrApuyEFX8cWoB1Ow243Cd8s44ujYgsTNgHe0jt6MGPo 3JKqFlye/WqmSfMQ6L4iDfC+H54s19HMlfDPRS9d2A26ormHluUQIigQamtHppg+mwqNc4 CaRAUOwtx69KfH1vY7Q9KrpE2ePC9xg= 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 B9A3513580; Mon, 25 Sep 2023 12:37:30 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id bfVgKgp/EWUQcQAAMHmgww (envelope-from ); Mon, 25 Sep 2023 12:37:30 +0000 Date: Mon, 25 Sep 2023 14:37:29 +0200 From: Michal Hocko To: Haifeng Xu Cc: hannes@cmpxchg.org, roman.gushchin@linux.dev, shakeelb@google.com, cgroups@vger.kernel.org, linux-mm@kvack.org Subject: Re: [PATCH 1/2] memcg, oom: unmark under_oom after the oom killer is done Message-ID: References: <20230922070529.362202-1-haifeng.xu@shopee.com> <6b7af68c-2cfb-b789-4239-204be7c8ad7e@shopee.com> <94b7ed1d-9ca8-7d34-a0f4-c46bc995a3d2@shopee.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <94b7ed1d-9ca8-7d34-a0f4-c46bc995a3d2@shopee.com> X-Rspamd-Queue-Id: A85EB40003 X-Rspam-User: X-Rspamd-Server: rspam02 X-Stat-Signature: nnotatiasrzyuh5j3pebe6qyq4np5ik9 X-HE-Tag: 1695645452-974554 X-HE-Meta: U2FsdGVkX19Rv/tLOHPXdfYHgWQr2Ohv2BvXqnIxdUzMtJFzzojXmIqDH5YzkR9qCQ2vuC+n0NZOjTYSUgQ5NBlwWN+9jXGjAP4cf3OtYHiJptDL5Ua8SQwRydeoi6/uMQyKTK3gxWhyvB3QsBPcM7lOmIFAhQXHQ2/0KO+uonFi5J9dXDiP2s/eaVyCTf1DG1kCUl56ohvoIx51ATmOGv/mIbldiNPb5dzYcN2eh9R02HR1ebGRTSbszSn5XZqjWc3H2wXh4Zx5YCkZ0z+gVn9MbDZzmCwnilOAl/lLY99Gju9146W+gvPLAwZihyZAVs5oocIfsgsId7tlnkTuPSauK+nSNOR08XlNMc12G2nSTv6ZFBYD2sXJbWKELoJyYLtNop6kny+KDBUq/WhfZ56Xjuz4fE6+IHp959XRWqMhLAQlPxqLQDCBhyFk/ZwG2rKkm4aol5otKbG2+MUN2UANVtCj8VdkjoN6mjtn5xW/IkPRFUNADLvJml8dHcD3Oj6oHlHJeU0n37xpRK5lZAsxEq3C2EroynX+DNrRblFkzaq+Cn88fSzmp91YcjTstTkSkSLUUe3RUcTuRQHew/xHGVdpyCO/FCGynQM3VPX1IXDCUNnWfDkLvVh2JbPu5Bn6idm0hfQGXhAQlsMpgWbqWdowvo+9XtZAxVAyDzOulA2K0xefdtVDrIXI3A4ssW7CTLt/cELdEs6Mluf4qEffIZiz8xrIkPZXqrS1RTo5uZIjaCLgX34Ou22lq1sA4uLAss28jjGxwtvY91gDgqmEIkB9Drdk1sEGS1WAezhQdg1SOSP48Xl26W46PS7RM87SkqeZ5g0ADUQ21qAR19uv8+jucVEgS2CB0HwlszQIyrdyz5Wco6C0a2D72O394bgAIdhOI4kfL24cJBQu1eR5t9vEvVTKTISzaGPWOrpqq8B0f/01CsZtj3Q2ZFhLqG5xqqDNS0GGf7Cf/vg hRH3UmYf 7miW6Pyq5bi5TQDvm35ISJT9dIyVHE/qypM2+PNYmVd/T1B2WXBxrbnNwn3sK4+18WB1AsDmy+XNTzrK+n5clil2jprHs/6VJRmrUqOH9ucEVY22uvM5hTkjYAlKUIgqhRHXNJvtWnfLoi0Flvy6LEbGMzxicXGIWyUijDkWlcfJoS1rxK9l1/MRLKgD6K1x/QFHz 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 25-09-23 20:28:02, Haifeng Xu wrote: > > > On 2023/9/25 19:38, Michal Hocko wrote: > > On Mon 25-09-23 17:03:05, Haifeng Xu wrote: > >> > >> > >> On 2023/9/25 15:57, Michal Hocko wrote: > >>> On Fri 22-09-23 07:05:28, Haifeng Xu wrote: > >>>> When application in userland receives oom notification from kernel > >>>> and reads the oom_control file, it's confusing that under_oom is 0 > >>>> though the omm killer hasn't finished. The reason is that under_oom > >>>> is cleared before invoking mem_cgroup_out_of_memory(), so move the > >>>> action that unmark under_oom after completing oom handling. Therefore, > >>>> the value of under_oom won't mislead users. > >>> > >>> I do not really remember why are we doing it this way but trying to track > >>> this down shows that we have been doing that since fb2a6fc56be6 ("mm: > >>> memcg: rework and document OOM waiting and wakeup"). So this is an > >>> established behavior for 10 years now. Do we really need to change it > >>> now? The interface is legacy and hopefully no new workloads are > >>> emerging. > >>> > >>> I agree that the placement is surprising but I would rather not change > >>> that unless there is a very good reason for that. Do you have any actual > >>> workload which depends on the ordering? And if yes, how do you deal with > >>> timing when the consumer of the notification just gets woken up after > >>> mem_cgroup_out_of_memory completes? > >> > >> yes, when the oom event is triggered, we check the under_oom every 10 seconds. If it > >> is cleared, then we create a new process with less memory allocation to avoid oom again. > > > > OK, I do understand what you mean and I could have made myself > > more clear previously. Even if the state is cleared _after_ > > mem_cgroup_out_of_memory then you won't get what you need I am > > afraid. The memcg stays under OOM until a memory is freed (uncharged) > > from that memcg. mem_cgroup_out_of_memory itself doesn't really free > > any memory on its own. It relies on the task to wake up and die or > > oom_reaper to do the work on its behalf. All of that is time dependent. > > under_oom would have to be reimplemented to be cleared when a memory is > > unchanrged to meet your demands. Something that has never really been > > the semantic. > > > > yes, but at least before we create the new process, it has more chance to get some memory freed. The time window we are talking about is the call of mem_cgroup_out_of_memory which, depending on the number of evaluated processes, could be a very short time. So what kind of practical difference does this have on your workload? Is this measurable in any way. > > Btw. is this something new that you are developing on top of v1? And if > > yes, why don't you use v2? > > > > yes, v2 doesn't have the "cgroup.event_control" file. Yes, it doesn't. But why is it necessary? Relying on v1 just for this is far from ideal as v1 is deprecated and mostly frozen. Why do you need to rely on the oom notifications (or oom behavior in general) in the first place? Could you share more about your workload and your requirements? -- Michal Hocko SUSE Labs