Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp3375779yba; Tue, 23 Apr 2019 02:42:33 -0700 (PDT) X-Google-Smtp-Source: APXvYqyyQHKNJ/BzTpR0H+BG/3nX1Wtbq0RH6hGVijjXFu3mh1c64VuyKdBO+nJTzDITz3ZB3P56 X-Received: by 2002:a65:5049:: with SMTP id k9mr22948907pgo.229.1556012553264; Tue, 23 Apr 2019 02:42:33 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1556012553; cv=none; d=google.com; s=arc-20160816; b=xSJSZHZy27Zhlc72WccoQvBE9X8j8+dmgpIwxSoZnDS950J/V/ZlmZQ5uCGs01UIA+ 2iSZ5a1UdxvVWiDhTA1Zo80fbVrpiKugIfOTUX/ny2KC8DjEeYonOT+sfJgCeCLn0TOn fpveE/1c9VU2exhZ94Eun5TWwKP9P9zAr7LMpEZoOFVAFLdTc9RH1QMZseMcZP9a4Ixx PNcpAGR1I490rNLG/0GELOT2tQuUjUk9wC1YPaGQDNE7mtm4MjnzfrnACL7XqBiO+Ebz bxS4fs48HdxeQox5XGHZNqreVx2twaemBpWs51fQVeBIvQ9eNeBD5BWt9aiJGYPd3bhE q8Mg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject; bh=2uob2F3Kx6TW0ByX6Nfo89dOAaZeH4eT8fFX6/yrdPw=; b=Juv8rz8cKyH/ZpnOCYTH6cZdwYYU45LygPZZPoK8ogBuLgwISy4ep1MyISXoKuUMQ1 6nFzn8YYA+aaTIfHBz5sY1TFMcXINysAn3Tn8AmgRamtyR+WC8GfybTrk9rPizB3OsC+ IeMlvByHVlqHl3LhQsdvyxU1apHV0I4vmdeZ6ACwR2tqV3/zuXDjRZDgceo+dRRA1mW1 BNsXjooIoe2kpGlXvxF+VVW7EiDWQo4uzZyE2WfPagdaYX+hQfSc925phdQHfuZz9B5i Xf5LK86V0Yvfx308SJJ63i0plqAgkIFRP74kM62Pnuju3l+gRDwCT/F/NCF3ymLwLSJV /K5w== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=alibaba.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id t14si15598964pfh.87.2019.04.23.02.42.18; Tue, 23 Apr 2019 02:42:33 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=alibaba.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727229AbfDWJlO (ORCPT + 99 others); Tue, 23 Apr 2019 05:41:14 -0400 Received: from out30-54.freemail.mail.aliyun.com ([115.124.30.54]:60839 "EHLO out30-54.freemail.mail.aliyun.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725990AbfDWJlO (ORCPT ); Tue, 23 Apr 2019 05:41:14 -0400 X-Alimail-AntiSpam: AC=PASS;BC=-1|-1;BR=01201311R111e4;CH=green;DM=||false|;FP=0|-1|-1|-1|0|-1|-1|-1;HT=e01e01422;MF=yun.wang@linux.alibaba.com;NM=1;PH=DS;RN=7;SR=0;TI=SMTPD_---0TQ1rapc_1556012469; Received: from testdeMacBook-Pro.local(mailfrom:yun.wang@linux.alibaba.com fp:SMTPD_---0TQ1rapc_1556012469) by smtp.aliyun-inc.com(127.0.0.1); Tue, 23 Apr 2019 17:41:10 +0800 Subject: Re: [RFC PATCH 3/5] numa: introduce per-cgroup preferred numa node To: Peter Zijlstra Cc: hannes@cmpxchg.org, mhocko@kernel.org, vdavydov.dev@gmail.com, Ingo Molnar , linux-kernel@vger.kernel.org, linux-mm@kvack.org References: <209d247e-c1b2-3235-2722-dd7c1f896483@linux.alibaba.com> <77452c03-bc4c-7aed-e605-d5351f868586@linux.alibaba.com> <20190423085533.GF11158@hirez.programming.kicks-ass.net> From: =?UTF-8?B?546L6LSH?= Message-ID: Date: Tue, 23 Apr 2019 17:41:09 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: <20190423085533.GF11158@hirez.programming.kicks-ass.net> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2019/4/23 δΈ‹εˆ4:55, Peter Zijlstra wrote: > On Mon, Apr 22, 2019 at 10:13:36AM +0800, ηŽ‹θ΄‡ wrote: >> diff --git a/mm/mempolicy.c b/mm/mempolicy.c >> index af171ccb56a2..6513504373b4 100644 >> --- a/mm/mempolicy.c >> +++ b/mm/mempolicy.c >> @@ -2031,6 +2031,10 @@ alloc_pages_vma(gfp_t gfp, int order, struct vm_area_struct *vma, >> >> pol = get_vma_policy(vma, addr); >> >> + page = alloc_page_numa_preferred(gfp, order); >> + if (page) >> + goto out; >> + >> if (pol->mode == MPOL_INTERLEAVE) { >> unsigned nid; >> > > This I think is wrong, it overrides app specific mbind() requests. The original concern is that we scared the user apps insider cgroup deal wrong with memory policy and do bad behavior, but now I agree that we should not override the policy, the admin will take the responsibility. Regards, Michael Wang >