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.3 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 65A49C12002 for ; Thu, 15 Jul 2021 02:13:23 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id D397E613CA for ; Thu, 15 Jul 2021 02:13:22 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org D397E613CA 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 E607C8D000E; Wed, 14 Jul 2021 22:13:22 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id E10458D000A; Wed, 14 Jul 2021 22:13:22 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id CB03C8D000E; Wed, 14 Jul 2021 22:13:22 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0089.hostedemail.com [216.40.44.89]) by kanga.kvack.org (Postfix) with ESMTP id 9E4A78D000A for ; Wed, 14 Jul 2021 22:13:22 -0400 (EDT) Received: from smtpin27.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 8ECCC824805A for ; Thu, 15 Jul 2021 02:13:21 +0000 (UTC) X-FDA: 78363200202.27.9D97227 Received: from mga05.intel.com (mga05.intel.com [192.55.52.43]) by imf29.hostedemail.com (Postfix) with ESMTP id 4205D900013E for ; Thu, 15 Jul 2021 02:13:19 +0000 (UTC) X-IronPort-AV: E=McAfee;i="6200,9189,10045"; a="296104076" X-IronPort-AV: E=Sophos;i="5.84,240,1620716400"; d="scan'208";a="296104076" Received: from orsmga008.jf.intel.com ([10.7.209.65]) by fmsmga105.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 14 Jul 2021 19:13:08 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.84,240,1620716400"; d="scan'208";a="460200285" Received: from shbuild999.sh.intel.com (HELO localhost) ([10.239.146.151]) by orsmga008.jf.intel.com with ESMTP; 14 Jul 2021 19:13:04 -0700 Date: Thu, 15 Jul 2021 10:13:03 +0800 From: Feng Tang To: Andrew Morton Cc: linux-mm@kvack.org, Michal Hocko , David Rientjes , Dave Hansen , Ben Widawsky , linux-kernel@vger.kernel.org, linux-api@vger.kernel.org, Andrea Arcangeli , Mel Gorman , Mike Kravetz , Randy Dunlap , Vlastimil Babka , Andi Kleen , Dan Williams , ying.huang@intel.com Subject: Re: [PATCH v6 0/6] Introduce multi-preference mempolicy Message-ID: <20210715021303.GA66164@shbuild999.sh.intel.com> References: <1626077374-81682-1-git-send-email-feng.tang@intel.com> <20210714171540.7cb9e221d683b531928b71f5@linux-foundation.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210714171540.7cb9e221d683b531928b71f5@linux-foundation.org> User-Agent: Mutt/1.5.24 (2015-08-30) X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 4205D900013E X-Stat-Signature: yb65eix47u18zbccpap68j7uyomd6mj7 Authentication-Results: imf29.hostedemail.com; dkim=none; spf=none (imf29.hostedemail.com: domain of feng.tang@intel.com has no SPF policy when checking 192.55.52.43) smtp.mailfrom=feng.tang@intel.com; dmarc=fail reason="No valid SPF, No valid DKIM" header.from=intel.com (policy=none) X-HE-Tag: 1626315199-360253 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 Andrew, Thanks for reviewing! On Wed, Jul 14, 2021 at 05:15:40PM -0700, Andrew Morton wrote: > On Mon, 12 Jul 2021 16:09:28 +0800 Feng Tang wrote: > > > This patch series introduces the concept of the MPOL_PREFERRED_MANY mempolicy. > > This mempolicy mode can be used with either the set_mempolicy(2) or mbind(2) > > interfaces. Like the MPOL_PREFERRED interface, it allows an application to set a > > preference for nodes which will fulfil memory allocation requests. Unlike the > > MPOL_PREFERRED mode, it takes a set of nodes. Like the MPOL_BIND interface, it > > works over a set of nodes. Unlike MPOL_BIND, it will not cause a SIGSEGV or > > invoke the OOM killer if those preferred nodes are not available. > > Do we have any real-world testing which demonstrates the benefits of > all of this? We have done some internal tests, and are actively working with some external customer on using this new 'prefer-many' policy, as they have different types of memory (fast DRAM and slower Persistent memory) in system, and their program wants to set clear preference for several NUMA nodes, to better deploy the huge application data before running the application. We have met another issue that customer wanted to run a docker container while binding it to 2 persistent memory nodes, which always failed. At that time we tried 2 hack pachtes to solve it. https://lore.kernel.org/lkml/1604470210-124827-2-git-send-email-feng.tang@intel.com/ https://lore.kernel.org/lkml/1604470210-124827-3-git-send-email-feng.tang@intel.com/ And that use case can be easily achieved with this new policy. Thanks, Feng