Received: by 2002:a05:6a10:f3d0:0:0:0:0 with SMTP id a16csp865826pxv; Wed, 14 Jul 2021 17:55:55 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxozD+osJrBhQh6TUh2SJtmvvX8KfPqM+KPYSzF2EzTyeZRKq+Yua5JdHDROftotsS/Mumg X-Received: by 2002:a17:906:7012:: with SMTP id n18mr1119413ejj.236.1626310555567; Wed, 14 Jul 2021 17:55:55 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1626310555; cv=none; d=google.com; s=arc-20160816; b=KkEV/I4I09gBkNWuRWR4xc4w83YBUyebvxaazQJE6e/qPweA+Hih4QKX0vPZuw3pJ8 EJjmCl7AjxxdGzwQ2gxiL6Dr5721eGAkDBEt/woHsDMP42iAxKZ6uaNMl5lvkwn6niEx LeWDlRA+d0Je/cA9JyfgvMpTGdL1TWLSmC4Sr0AM7d1hi8vfORdmg43U/LMWSkRmesq1 JYHkjXOtOo9m6klG2/W+nXqwmXzLJ2ZKYD3iGRGFXUlZcbJP0OROuYGvMYbxkF8fWJ7o tUDlalwsO5H2pU3bb8uQhmg1LdPQKVE7zPo4z7Vj0aXUvZTpOSKHl2F2P2Yj8TNEAXCy j0kQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:subject:cc:to:from:date :dkim-signature; bh=Fqy8q1GvFf2rB7W7o9rtwviSp4fk5KSMK7Dm5WpYiWs=; b=RisEyoaPCbxoqRMRsvz85wqZE/rxcjQQ7Ig8+g+GsJpxF4ujWYTD9IF9g4X0kCBSJk I+XDPsZvpW+oExAKIBUjVZyKj6JnsTEX8RMk3jn3KDUQwDRPjWQIpSE7iiu8YTNCz294 NZXMc2ZzEbnW7m1kZhJfvsZdxkhO75+WH+LgMqRHVVmTLT3OqFqKq9y0WRP0D5tQrty5 MlBnwA5YWozmTz7D8/iwW/RMtLfoHzr2oGEa9Tp/mDbwHEuJIZj5kkxN1p61wXO0tPvj GDgI8dihh3NNyMHy6IaIoAWdVq/Gf5gVWac3MAh9OwkMHN3g+rgHbKrjR0ucdxFDWzmL YvVw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linux-foundation.org header.s=korg header.b=g8YCHlp5; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id y62si4626376ede.555.2021.07.14.17.55.32; Wed, 14 Jul 2021 17:55:55 -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; dkim=pass header.i=@linux-foundation.org header.s=korg header.b=g8YCHlp5; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236767AbhGOASf (ORCPT + 99 others); Wed, 14 Jul 2021 20:18:35 -0400 Received: from mail.kernel.org ([198.145.29.99]:50498 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236618AbhGOASf (ORCPT ); Wed, 14 Jul 2021 20:18:35 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id 6CE62613CA; Thu, 15 Jul 2021 00:15:41 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org; s=korg; t=1626308141; bh=Fqy8q1GvFf2rB7W7o9rtwviSp4fk5KSMK7Dm5WpYiWs=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=g8YCHlp5dl396g1XhSIrqvKv6404oJvcet/t5nsbAMYxTPIwDKWhsOLAw7q0im44e 5t+wMUNKUUq2KB8Rcf/qvw0WNlH5+NTBtRQUW77eTUXq3bZ1+4KLnGxiBRtJ5m79vy zK1XaU5NL8xb/tp1CaEO/M8HUjtFxKiXxQ7gt+ss= Date: Wed, 14 Jul 2021 17:15:40 -0700 From: Andrew Morton To: Feng Tang 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: <20210714171540.7cb9e221d683b531928b71f5@linux-foundation.org> In-Reply-To: <1626077374-81682-1-git-send-email-feng.tang@intel.com> References: <1626077374-81682-1-git-send-email-feng.tang@intel.com> X-Mailer: Sylpheed 3.5.1 (GTK+ 2.24.31; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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?