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 39A00C433EF for ; Tue, 12 Jul 2022 13:35:34 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id CA293940074; Tue, 12 Jul 2022 09:35:33 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id C530E940063; Tue, 12 Jul 2022 09:35:33 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B1A94940074; Tue, 12 Jul 2022 09:35:33 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id A16BB940063 for ; Tue, 12 Jul 2022 09:35:33 -0400 (EDT) Received: from smtpin18.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay13.hostedemail.com (Postfix) with ESMTP id 6E2736012E for ; Tue, 12 Jul 2022 13:35:33 +0000 (UTC) X-FDA: 79678544946.18.2D2D4B2 Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.220.29]) by imf19.hostedemail.com (Postfix) with ESMTP id CF8A31A006F for ; Tue, 12 Jul 2022 13:35:32 +0000 (UTC) Received: from relay2.suse.de (relay2.suse.de [149.44.160.134]) by smtp-out2.suse.de (Postfix) with ESMTP id 59F5920151; Tue, 12 Jul 2022 13:35:31 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1657632931; 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=+zipOz8mXTXKTOJCGZnBsxuqw/eZ2Vsh+kILV8kuqxE=; b=VWaLz0Zi9WuzNQOHKOhhmJXt/adh3j2q5b/mwzjcUHqDNxLTThxGq10ppyCwcdaoz7LMJG fBbTccaLbUuIIasDGhIXlz9896nN1pgO6K/iJTc8czSOkvt1q+ktZaXXGkXoZPK7wf7wTq M3ccS3h7L6Y79Ux6ZHqhmnY5IB03Juw= 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 4DFB72C141; Tue, 12 Jul 2022 13:35:29 +0000 (UTC) Date: Tue, 12 Jul 2022 15:35:28 +0200 From: Michal Hocko To: Abel Wu Cc: Gang Li , akpm@linux-foundation.org, surenb@google.com, hca@linux.ibm.com, gor@linux.ibm.com, agordeev@linux.ibm.com, borntraeger@linux.ibm.com, svens@linux.ibm.com, viro@zeniv.linux.org.uk, ebiederm@xmission.com, keescook@chromium.org, rostedt@goodmis.org, mingo@redhat.com, peterz@infradead.org, acme@kernel.org, mark.rutland@arm.com, alexander.shishkin@linux.intel.com, jolsa@kernel.org, namhyung@kernel.org, david@redhat.com, imbrenda@linux.ibm.com, adobriyan@gmail.com, yang.yang29@zte.com.cn, brauner@kernel.org, stephen.s.brennan@oracle.com, zhengqi.arch@bytedance.com, haolee.swjtu@gmail.com, xu.xin16@zte.com.cn, Liam.Howlett@oracle.com, ohoono.kwon@samsung.com, peterx@redhat.com, arnd@arndb.de, shy828301@gmail.com, alex.sierra@amd.com, xianting.tian@linux.alibaba.com, willy@infradead.org, ccross@google.com, vbabka@suse.cz, sujiaxun@uniontech.com, sfr@canb.auug.org.au, vasily.averin@linux.dev, mgorman@suse.de, vvghjk1234@gmail.com, tglx@linutronix.de, luto@kernel.org, bigeasy@linutronix.de, fenghua.yu@intel.com, linux-s390@vger.kernel.org, linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, linux-perf-users@vger.kernel.org, hezhongkun.hzk@bytedance.com Subject: Re: [PATCH v2 0/5] mm, oom: Introduce per numa node oom for CONSTRAINT_{MEMORY_POLICY,CPUSET} Message-ID: References: <20220708082129.80115-1-ligang.bdlg@bytedance.com> <41ae31a7-6998-be88-858c-744e31a76b2a@bytedance.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <41ae31a7-6998-be88-858c-744e31a76b2a@bytedance.com> ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1657632933; a=rsa-sha256; cv=none; b=v1N/eLIr44aBwygqRjIwiSUHl1SE+ids1mA7ymG5pqiW+32zhPSnILyYmYy8rSD+Bhl+/Z g/uQIORcQmV8r8lDqdfYUwZK3Y0Va9c2LPH3nEz2C6q0KUrJEY1YSn1EP+SLOYL0+vhOh+ y+YzZHLmUEKNk2RLpmuxI1lN1U1xpHk= ARC-Authentication-Results: i=1; imf19.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b=VWaLz0Zi; spf=pass (imf19.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=1657632933; 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=+zipOz8mXTXKTOJCGZnBsxuqw/eZ2Vsh+kILV8kuqxE=; b=dLGGcqeeYY2+pD9PUfuws0Z2lmRPQndiYD92awzlrPYE3QLywyMTD3P2NLTfpyVp70F7/C gzzBp2MOpf9QKmUxI7yMve+m/TRubnMKNSza/3YsFcjl8IDtcN9eR0PTjDHSGPRqrxDGeQ VcATERZBJiQgF25OOwid9tsTiXTCrUg= X-Rspamd-Queue-Id: CF8A31A006F Authentication-Results: imf19.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b=VWaLz0Zi; spf=pass (imf19.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: rspam02 X-Rspam-User: X-Stat-Signature: 3ei6uq1byt8fdremcqgymni53361ryjq X-HE-Tag: 1657632932-508920 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 Tue 12-07-22 19:12:18, Abel Wu wrote: [...] > I was just going through the mail list and happen to see this. There > is another usecase for us about per-numa memory usage. > > Say we have several important latency-critical services sitting inside > different NUMA nodes without intersection. The need for memory of these > LC services varies, so the free memory of each node is also different. > Then we launch several background containers without cpuset constrains > to eat the left resources. Now the problem is that there doesn't seem > like a proper memory policy available to balance the usage between the > nodes, which could lead to memory-heavy LC services suffer from high > memory pressure and fails to meet the SLOs. I do agree that cpusets would be rather clumsy if usable at all in a scenario when you are trying to mix NUMA bound workloads with those that do not have any NUMA proferences. Could you be more specific about requirements here though? Let's say you run those latency critical services with "simple" memory policies and mix them with the other workload without any policies in place so they compete over memory. It is not really clear to me how can you achieve any reasonable QoS in such an environment. Your latency critical servises will be more constrained than the non-critical ones yet they are more demanding AFAIU. -- Michal Hocko SUSE Labs