Received: by 2002:a05:6a10:f3d0:0:0:0:0 with SMTP id a16csp80211pxv; Wed, 14 Jul 2021 19:34:22 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzAQZ0sLSczh3GA3zLh+zrIXX1FIel8sVJKXiXUL+EDBEUc8P2kpcNmXj4J2tmgBtx8Cvut X-Received: by 2002:a6b:7719:: with SMTP id n25mr1086861iom.37.1626316462287; Wed, 14 Jul 2021 19:34:22 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1626316462; cv=none; d=google.com; s=arc-20160816; b=iq6PQ7s1Xk8Ve6njUHFxWYU0HtOyK8fZvvJ86Jl+rGRIha3UuW9Uve8JOtDP88U20R i05kPamTBvajtLjlDQMO3kxuMByVO1CtQTbaSoi7kZGBLbMX9EWC3s7/fGrkmWWlKe1+ sVvFo6nhM5AqPFzLwmvDgVVxHF0JWdMcwFbvPHGdHXEq0eYOOYrqeRJ4imgraCUps0ze peXZWeqyiZqrA65sSc3ej6soFc2oZsLRcVE+7qhLI/VNAaniKaQOnIAo8205J3JYssRC Kahb8434oqkcVVR//7OpIIXTkwwywQCJ5SWRqeg/wUNhJszyp3ChQQuW8wEbEIQHH94G AeHA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date; bh=ivL1sycIUik6pXSqKKkb1kVRmCmbC6i8pOYRCamrHVU=; b=nbtYrFS2MiJwbg2McUAEkP3ryE1npl7Pli/+6W8NL/jIAdATwUvTlY7Vk8utxmWkBH NNTKdp0UMtu87YC2hi9kS7uD7gdIGpoIFh/vl+ZHsPP8LQBY+cblSAa87hL5AWDmxonk WZdISuY0E9Gy6UXvnXf8lMaLxvE+0e0oqmXyqPhw5elk5S16sTdHc+2gze+fj0NeW8AN 4HO39yEX6/kQOs6A5cZCy+3QAWz6T5xXzJ5xDBP1FKBZSaifH4HhAH90JhHxDN8vzBoa 8mdr54sz22wuJg9X8fc+MKZmWwZVyuNE/AvcxMKzCpZt6ubI+tbC6YIyvWJ7bFZcmgi1 FtVA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id t9si4961653jaj.20.2021.07.14.19.33.49; Wed, 14 Jul 2021 19:34:22 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231675AbhGOCQD (ORCPT + 99 others); Wed, 14 Jul 2021 22:16:03 -0400 Received: from mga12.intel.com ([192.55.52.136]:33170 "EHLO mga12.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231165AbhGOCQD (ORCPT ); Wed, 14 Jul 2021 22:16:03 -0400 X-IronPort-AV: E=McAfee;i="6200,9189,10045"; a="190141585" X-IronPort-AV: E=Sophos;i="5.84,240,1620716400"; d="scan'208";a="190141585" Received: from orsmga008.jf.intel.com ([10.7.209.65]) by fmsmga106.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) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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