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 X-Spam-Level: X-Spam-Status: No, score=-5.2 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 7B3F4C47089 for ; Thu, 27 May 2021 13:05:16 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 1009F610A2 for ; Thu, 27 May 2021 13:05:16 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 1009F610A2 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=intel.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id A93A16B006E; Thu, 27 May 2021 09:05:15 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id A69E36B0071; Thu, 27 May 2021 09:05:15 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 916006B006E; Thu, 27 May 2021 09:05:15 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0177.hostedemail.com [216.40.44.177]) by kanga.kvack.org (Postfix) with ESMTP id 609976B006E for ; Thu, 27 May 2021 09:05:15 -0400 (EDT) Received: from smtpin29.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id EF5DFAF9E for ; Thu, 27 May 2021 13:05:14 +0000 (UTC) X-FDA: 78187031748.29.CE42A08 Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by imf30.hostedemail.com (Postfix) with ESMTP id D0166E00082E for ; Thu, 27 May 2021 13:05:07 +0000 (UTC) IronPort-SDR: iaLQQbkM6m1dTk9MefcTfqjdHu6D3YhsL86ezM78QPaZXg89B7e5Vg7cbm74hneRYcZpq3v0Os KhYd/JHxyy2Q== X-IronPort-AV: E=McAfee;i="6200,9189,9996"; a="223929812" X-IronPort-AV: E=Sophos;i="5.82,334,1613462400"; d="scan'208";a="223929812" Received: from orsmga001.jf.intel.com ([10.7.209.18]) by fmsmga101.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 27 May 2021 06:05:06 -0700 IronPort-SDR: oDhBTO787SEsUd0BvLCjqWH/I/4+4Pv2FXxOSirzI2Vy5xJVKQOMGWbXBrD1LyiPaqFjbOkq9v sS7KCVK3f/vw== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.82,334,1613462400"; d="scan'208";a="477476320" Received: from shbuild999.sh.intel.com (HELO localhost) ([10.239.147.94]) by orsmga001.jf.intel.com with ESMTP; 27 May 2021 06:05:01 -0700 Date: Thu, 27 May 2021 21:05:01 +0800 From: Feng Tang To: Michal Hocko Cc: linux-mm@kvack.org, Andrew Morton , David Rientjes , Dave Hansen , Ben Widawsky , linux-kernel@vger.kernel.org, Andrea Arcangeli , Mel Gorman , Mike Kravetz , Randy Dunlap , Vlastimil Babka , Andi Kleen , Dan Williams , ying.huang@intel.com Subject: Re: [PATCH v1 1/4] mm/mempolicy: skip nodemask intersect check for 'interleave' when oom Message-ID: <20210527130501.GC7743@shbuild999.sh.intel.com> References: <1622005302-23027-1-git-send-email-feng.tang@intel.com> <1622005302-23027-2-git-send-email-feng.tang@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) X-Rspamd-Queue-Id: D0166E00082E Authentication-Results: imf30.hostedemail.com; dkim=none; spf=none (imf30.hostedemail.com: domain of feng.tang@intel.com has no SPF policy when checking 192.55.52.88) smtp.mailfrom=feng.tang@intel.com; dmarc=fail reason="No valid SPF, No valid DKIM" header.from=intel.com (policy=none) X-Rspamd-Server: rspam03 X-Stat-Signature: ng8je7f9zr15wix75b3fuemd78wg58q8 X-HE-Tag: 1622120707-790255 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 Thu, May 27, 2021 at 09:30:00AM +0200, Michal Hocko wrote: > On Wed 26-05-21 13:01:39, Feng Tang wrote: > > mempolicy_nodemask_intersects() is used in oom case to check if a > > task may have memory allocated on some memory nodes. > > > > Currently, the nodes_intersects() is run for both 'bind' and 'interleave' > > policies. But they are different regarding memory allocation, the nodemask > > is a forced requirement for 'bind', while just a hint for 'interleave'. > > Like in alloc_pages_vma(): > > > > nmask = policy_nodemask(gfp, pol); > > preferred_nid = policy_node(gfp, pol, node); > > page = __alloc_pages(gfp, order, preferred_nid, nmask); > > > > in plicy_nodemask(), only 'bind' policy may return its desired nodemask, > > while others return NULL. And this 'NULL' enables the 'interleave' policy > > can get memory from other nodes than its nodemask. > > > > So skip the nodemask intersect check for 'interleave' policy. > > The changelog is not really clear on the actual effect of the > patch and the above reference to alloc_pages_vma looks misleading to me > because that path is never called for interleaved policy. You are right. thanks for pointing it out. Only the 'bind' policy calls policy_nodemask() and gets its preset nodemask, while for 'interleave', alloc_page_interleave() calls __alloc_pages() with NULL nodemask, so the conclusion is the same that 'bind' policy can only get memory from its preset nodemask, while 'interleave' can get memory from all nodes. > This is very likely my fault because I was rather vague. The existing > code in its current form is confusing but it _works_ properly. The > problem is that it sounds like a general helper and in that regards > the function is correct for the interleaved policy and your proposed > preferred-many. But its only existing caller wants a different semantic. > > Until now this was not a real problem even for OOM context because > alloc_page_interleave is always used for the interleaving policy > and that one doesn't use any node mask so the code is not really > exercised. With your MPOL_PREFERRED this would no longer be the case. Given the 'interleave' task may have memory allocated from all nodes, shouldn't the mempolicy_nodemask_intersects() return true for 'interleave'? or I'm still missing something? > Your patch makes the code more robust for the oom context but it can > confuse other users who really want to do an intersect logic. So I think > it would really be best to rename the function and make it oom specific. > E.g. mempolicy_in_oom_domain(tsk, mask) this would make it clear that > this is not a general purpose function. Ok, will rename like this. Thanks, Feng > The changelog should be clear that this is just a code cleanup rather > than fix. > > -- > Michal Hocko > SUSE Labs