Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp3452235yba; Tue, 16 Apr 2019 11:36:33 -0700 (PDT) X-Google-Smtp-Source: APXvYqybO4y0+lfEWclSEYx2nm9EkOV2FBqsWqlxpnjdgm5tJhqbWjB5weOKgZ204QQD4uZxmnGF X-Received: by 2002:a63:1f52:: with SMTP id q18mr80163074pgm.134.1555439793332; Tue, 16 Apr 2019 11:36:33 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1555439793; cv=none; d=google.com; s=arc-20160816; b=ojjEhhbRQFYuLJkhNxDiBvB75Gp77PotgI6yNsNICrzYzJlnnQYPKKBvGxfWG07lQv 0hwmI6MV8mDMzBcZS7tx+Ocm64p08o2Ss98IcXxs1uJGKeiwUSKv8C5nl4QPe/eGeYS4 +rsYKYzPe5rkyIGqDK2KKPUTVecoLBu59EBU1dYUGA18iubkrdDvWSchfkfSGGabAgj5 aPPL7etoonBazY0vf4lrtQldPM5pfukKCqbQ5Y+wHnb6v4dKQ0EE4QhTGPzDHlHjbX7V crvwz4l9ydLVIZbFfNTmGAJzJPoYmtvguGUaCBGhmW7NhXn2Wls9rVWYzRacUdEjuYIA 1FNw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=NVleg4vxC5EidiKXiZI47idHwsmkAicZ+TYiKEWyOHg=; b=Y8ak/k9KQmq9Qa4R6cgf8OLWI+AYhAXgBW1ZGcsHzI0DVdu/Lxs+MqpVeYx2Kn5i1l kNuzJJ8mbaGIyM8kjVSLJEnmNtrwujBmFrGfiRW4if6yWxcmVar4XaAg4xvFlevrqwL7 lWjD7knDjy/ggsYDUnJdtiwjKy3rWhRfhNDlw+oV4z2L1Rrxf4MQCR97rehhNj7EQ9Cb ApBttBNzAG66igfiO9Rb7V6sCKCbOa7WZ1FSQCK5zm7akYJG9nctXSTGeakM1seh3kTJ xsFt4thKnZLXTxtgvnbGsTXAR1/UWPxL5M75WaJfrqR8k+a2V7RfWP0fnC1YlrsIJntj aa+Q== 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=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id q12si50332593pgh.594.2019.04.16.11.36.17; Tue, 16 Apr 2019 11:36: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=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729354AbfDPSeI (ORCPT + 99 others); Tue, 16 Apr 2019 14:34:08 -0400 Received: from mx2.suse.de ([195.135.220.15]:55898 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1727180AbfDPSeH (ORCPT ); Tue, 16 Apr 2019 14:34:07 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id 919C9AC58; Tue, 16 Apr 2019 18:34:06 +0000 (UTC) Date: Tue, 16 Apr 2019 20:34:04 +0200 From: Michal Hocko To: Dave Hansen Cc: Yang Shi , mgorman@techsingularity.net, riel@surriel.com, hannes@cmpxchg.org, akpm@linux-foundation.org, keith.busch@intel.com, dan.j.williams@intel.com, fengguang.wu@intel.com, fan.du@intel.com, ying.huang@intel.com, ziy@nvidia.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [v2 RFC PATCH 0/9] Another Approach to Use PMEM as NUMA Node Message-ID: <20190416183404.GA655@dhcp22.suse.cz> References: <1554955019-29472-1-git-send-email-yang.shi@linux.alibaba.com> <20190412084702.GD13373@dhcp22.suse.cz> <20190416074714.GD11561@dhcp22.suse.cz> <20190416143958.GI11561@dhcp22.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue 16-04-19 08:46:56, Dave Hansen wrote: > On 4/16/19 7:39 AM, Michal Hocko wrote: > >> Strict binding also doesn't keep another app from moving the > >> memory. > > I would consider that a bug. > > A bug where, though? Certainly not in the kernel. Kernel should refrain from moving explicitly bound memory nilly willy. I certainly agree that there are corner cases. E.g. memory hotplug. We do break CPU affinity for CPU offline as well. So this is something user should expect. But the kernel shouldn't move explicitly bound pages to a different node implicitly. I am not sure whether we even do that during compaction if we do then I would consider _this_ to be a bug. And NUMA rebalancing under memory pressure falls into the same category IMO. -- Michal Hocko SUSE Labs