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 458C7EE49A8 for ; Tue, 22 Aug 2023 06:31:55 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A7AAC940027; Tue, 22 Aug 2023 02:31:53 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id A040294000D; Tue, 22 Aug 2023 02:31:53 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8A47B940027; Tue, 22 Aug 2023 02:31:53 -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 7807694000D for ; Tue, 22 Aug 2023 02:31:53 -0400 (EDT) Received: from smtpin16.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 4F2A2A011B for ; Tue, 22 Aug 2023 06:31:53 +0000 (UTC) X-FDA: 81150770106.16.DDCEBA5 Received: from out-14.mta0.migadu.com (out-14.mta0.migadu.com [91.218.175.14]) by imf28.hostedemail.com (Postfix) with ESMTP id 49F28C0013 for ; Tue, 22 Aug 2023 06:31:51 +0000 (UTC) Authentication-Results: imf28.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=QMPCPA7F; spf=pass (imf28.hostedemail.com: domain of gang.li@linux.dev designates 91.218.175.14 as permitted sender) smtp.mailfrom=gang.li@linux.dev; dmarc=pass (policy=none) header.from=linux.dev ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1692685911; 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=PkmheFjFxExaCu9L5a48Fws0uehvzL2G5MIM97l1kY8=; b=ZwQcHNUooR9TGMqE4vVMfevMeZ0egfFoGxEtMsPsVMzUCUqqoEPGqXwqwQi0YlHYrIsGLN cPXPobqnukzd9aPSoge2BTFc7xGRmK5ZuVjZYrWFE72RnBIu+sGfrtQjwb7j3CNDN1DL9o PXXzrzK7bPlkXPrsspqo82CB3lIr7LQ= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1692685911; a=rsa-sha256; cv=none; b=pP+PWv02HYSHl/90A1UT0KL9FC/nPm9AnsUi6/S85anXBgAdPCdMpzxNPFzqO8imbOoulR T0gEnEuwYOfpNKeI2U1n8EwZUJKo/NpcHPAvy/c6oSBKM/gKAiPsb8btv/pwDt4554F5lE Aw3Q1gR9vjN1cLKhXxtekCx0Pvyt7D8= ARC-Authentication-Results: i=1; imf28.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=QMPCPA7F; spf=pass (imf28.hostedemail.com: domain of gang.li@linux.dev designates 91.218.175.14 as permitted sender) smtp.mailfrom=gang.li@linux.dev; dmarc=pass (policy=none) header.from=linux.dev Message-ID: <3ac6b49e-f605-6f8f-ba22-a411269cb818@linux.dev> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1692685909; h=from:from: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; bh=PkmheFjFxExaCu9L5a48Fws0uehvzL2G5MIM97l1kY8=; b=QMPCPA7FLfHqCiIiLXVPW69lDGE0fSXD2eJYvbjXmXmsgFpE/SjABJKQ/WbI6jyP0vVU8P QOGjpKqk+XX2DeE0jyNCysjqWaFWXWicyMZJZNtpMuoMcDIBQmB4q0Lp76NINGsMS2M+Pm 15JKLKEgl8zodMWAv3PMCxJ8/bcy5tc= Date: Tue, 22 Aug 2023 14:31:41 +0800 MIME-Version: 1.0 Subject: Re: [PATCH v4] mm: oom: introduce cpuset oom Content-Language: en-US X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Gang Li To: Michal Hocko , Waiman Long Cc: cgroups@vger.kernel.org, linux-mm@kvack.org, rientjes@google.com, Zefan Li , linux-kernel@vger.kernel.org, gang.li@linux.dev References: <20230411065816.9798-1-ligang.bdlg@bytedance.com> <9ba0de31-b9b8-fb10-011e-b24e9dba5ccd@linux.dev> In-Reply-To: <9ba0de31-b9b8-fb10-011e-b24e9dba5ccd@linux.dev> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Migadu-Flow: FLOW_OUT X-Rspamd-Queue-Id: 49F28C0013 X-Rspam-User: X-Rspamd-Server: rspam11 X-Stat-Signature: q834phijyzmw5jyj1ajahbb8u5cro41c X-HE-Tag: 1692685911-408115 X-HE-Meta: U2FsdGVkX19UFIz7n+RIVtPvEuBzUaJyaO8yWIgq3gdR/pyiczTp2oXZ8diafORb5pLK+SFeyJvvqxYwrhMMRSKfX1FyPN0IYV4+bGsbEu86Pr11SJWOjfuxbAhG5pw2RvQphj4B5FCErCMu+sOjePGWA8JbTxLKirC8GrFalvQ6INDJvJUjQ+A0MdonF5bJJ37aUPsSHuP5PlzlGhqymKRHpxXpFd6cKlqJhJc05B+pjSC6wfqqALT9EjW9VnyfnL84y5PgmOJk5a9Z4isq+zWa+YTTmpAbVCaBsXvkuR8XtyzIuTRCoh0O8iITssTtesG2LPo17uhbC0LYqy/mgnkZttIU0owNW/w69C5zDuapzeTLMIOoh0Jcu64703Ns+3+vIhp81LKpmzCFJV0MZ4Oy+BXOuPF6iBsG4DcV0TaRwzCpVIKMNdn0yPz8VKoMsRLLVJ4iNC83c70amwQwrvZ2eSdQJ62I5htfLgOLXFGP9FcGd6Xpl5oZZDw1u+XNjXMX1bWTKNHfwY5tYlrO0R39ssBU9pyZtPRAKUsiNzBjSFPBTnSPQaRaCOcxFQTsS24Z5ciqo4Tfare90YnXOZag815zasFnmNBW2RIDNEF8Tgg+Ry4+Mg+kvYzkxASg/fbs/O7hN1FnmEM9MO8GHcp0AICxW4Ws3/c/aoRp0tHchJu8uphEl5ub+1x4rqONMIPYJWyXKu3peCkt4m1OCbHNIVI0f91nLNiVPudJtYLdKYC06pqlfPvIxPAfd9XP1l1kqztnIgT1ylEKuYHdKbZ/4+8PDPsxWRhwt62FvFWzD716gkEKNlOKdQmBSRYoRq8lIE1pOE+PjgLbvgHUsn+n0uGA7W5XnvI54u0/2WQ3WhJW65uSKnt+5BtF04iRNqAG7OWYwxFOzBMXsLK2lm2nQfEBjJR57pn3QQJyYxJEAwuUblJMXT4ChzshTQUZrK7RFA3CLcl3oflxNDU IhKoMNBh mwOO1DSbTF6nh2G7ziqAoJf+iohRW/71u48OqWp2K1sYvMW7Mw0XCCQN0KL2WAT8r4/K3R7/zILYlLew= 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: Hi, On 2023/8/17 16:40, Gang Li wrote: > On 2023/4/11 22:36, Michal Hocko wrote: >> I believe it still wouldn't hurt to be more specific here. >> CONSTRAINT_CPUSET is rather obscure. Looking at this just makes my head >> spin. >>          /* Check this allocation failure is caused by cpuset's wall >> function */ >>          for_each_zone_zonelist_nodemask(zone, z, oc->zonelist, >>                          highest_zoneidx, oc->nodemask) >>                  if (!cpuset_zone_allowed(zone, oc->gfp_mask)) >>                          cpuset_limited = true; >> > Does this even work properly and why? prepare_alloc_pages sets >> oc->nodemask to current->mems_allowed but the above gives us >> cpuset_limited only if there is at least one zone/node that is not >> oc->nodemask compatible. So it seems like this wouldn't ever get set >> unless oc->nodemask got reset somewhere. This is a maze indeed.Is there > > In __alloc_pages: > ``` > /* >  * Restore the original nodemask if it was potentially replaced with >  * &cpuset_current_mems_allowed to optimize the fast-path attempt. >  */ > ac.nodemask = nodemask; > page = __alloc_pages_slowpath(alloc_gfp, order, &ac); > > ``` > > __alloc_pages set ac.nodemask back to mempolicy before call > __alloc_pages_slowpath. > > >> any reason why we cannot rely on __GFP_HARWALL here? Or should we > > In prepare_alloc_pages: > ``` > if (cpusets_enabled()) { >     *alloc_gfp |= __GFP_HARDWALL; >     ... > } > ``` > > Since __GFP_HARDWALL is set as long as cpuset is enabled, I think we can > use it to determine if we are under the constraint of CPUSET. > We have two nodemasks: one from the parameters of __alloc_pages and another from cpuset. If the node allowed by the parameters of __alloc_pages is not allowed by cpuset, it means that this page allocation is constrained by cpuset, and thus CONSTRAINT_CPUSET can be returned. I guess this piece of code is reasonable and we can keep the code as it is. Thanks, Gang Li.