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=-0.8 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED 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 30B4CCA9EAB for ; Fri, 18 Oct 2019 21:55:25 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id E3DB6222C3 for ; Fri, 18 Oct 2019 21:55:24 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=intel-com.20150623.gappssmtp.com header.i=@intel-com.20150623.gappssmtp.com header.b="W4C6i/ND" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org E3DB6222C3 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 7B6CE8E0006; Fri, 18 Oct 2019 17:55:24 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 766968E0003; Fri, 18 Oct 2019 17:55:24 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 67D6E8E0006; Fri, 18 Oct 2019 17:55:24 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0250.hostedemail.com [216.40.44.250]) by kanga.kvack.org (Postfix) with ESMTP id 475698E0003 for ; Fri, 18 Oct 2019 17:55:24 -0400 (EDT) Received: from smtpin25.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with SMTP id D06041F20E for ; Fri, 18 Oct 2019 21:55:23 +0000 (UTC) X-FDA: 76058262126.25.paste20_6939915522f61 X-HE-Tag: paste20_6939915522f61 X-Filterd-Recvd-Size: 4556 Received: from mail-oi1-f194.google.com (mail-oi1-f194.google.com [209.85.167.194]) by imf39.hostedemail.com (Postfix) with ESMTP for ; Fri, 18 Oct 2019 21:55:22 +0000 (UTC) Received: by mail-oi1-f194.google.com with SMTP id a15so6501870oic.0 for ; Fri, 18 Oct 2019 14:55:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=intel-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=1tyLVKIt7fjiqKhGVwZeZKRmV2ktkcmCU7XGltvDQ4Q=; b=W4C6i/NDHXV4LLEEcdB1w1FdhP89pXSPKd2RgTguGpRoA0RN+eJfpijKXmMkoMu7uE 8zXAPl1V6RsLuTk3j3JFviHk8fFjb4BwsCDZ0PtGFFk7Zj+Xy+hlQXCJn28kbLjwSf8A TJMtBFv+uAaOjsrYKHGK2vfazgo86mlD4PQj52Wsd+pTOx/5fCPk219aQrYfk4OYQOUk HgfmZJQYmbtiqHIYlg6Qws7HbGjUDr1iYJQmMdS1lgDVGqMZxmKsKRU/KqAW57ON50ms V76vXWR+JiMA0mcdN6nZh0At9rdNNNwrD6ufyycGKkHUsODex8SYQzXnhgQDgutegrkG m+bA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=1tyLVKIt7fjiqKhGVwZeZKRmV2ktkcmCU7XGltvDQ4Q=; b=EU9pNAXFpngjGuPW3K23vx5S4upn+TIeGE6uho8ooiVX/F2hm1G4szatvdz3D4e8oa vCEx1KIjdqlk96TfQ76xL7RR1prML0r5set1fXnU6h15VKblHwjWmRp5L+GbDyWjwuG1 Dw+9QN7S9WdCxJAVUfZ5FN3M6d/Z0pDpElVFOKt9f4x0H4FfMREkoG3Uc0NXP8sPNqn9 ks1p4yV1sreCfXkFlm0jBB3t07lWJNFVQ+D/NpQzQQjnK1SCfioq1RCtN5YTzeGeiIBx 1DOFHg05C1O2T4X9Nc7QomeU5xtSJeX0pVSFz+Tb3FWIyM0k3bwDXUJsfkfm4vGkbfVp SYdQ== X-Gm-Message-State: APjAAAUQ7NBXK7NfVJci3O1Rc/hK64HYlqtZ9cRXcKIhJFEc2jp5ebF0 WaYTle9LzSZsoqDmpxbJ3+G/bezP44mjL3Yp6FPcfQ== X-Google-Smtp-Source: APXvYqwPrLJc1RKs4wL7hY5OVAhRvD33SHPKSYPl2GR1GyyYLqGRZmB2kxuweWXNo7u69Brz3dEU3JReHhozkB8NYEY= X-Received: by 2002:aca:6087:: with SMTP id u129mr10127312oib.149.1571435722239; Fri, 18 Oct 2019 14:55:22 -0700 (PDT) MIME-Version: 1.0 References: <20191016221148.F9CCD155@viggo.jf.intel.com> <20191018074411.GC5017@dhcp22.suse.cz> <0b05c135-4762-e745-5289-58ee84cc8c3e@intel.com> In-Reply-To: From: Dan Williams Date: Fri, 18 Oct 2019 14:55:11 -0700 Message-ID: Subject: Re: [PATCH 0/4] [RFC] Migrate Pages in lieu of discard To: Yang Shi Cc: Dave Hansen , Michal Hocko , Dave Hansen , Linux Kernel Mailing List , Linux MM Content-Type: text/plain; charset="UTF-8" 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: On Fri, Oct 18, 2019 at 2:40 PM Yang Shi wrote: > > On Fri, Oct 18, 2019 at 7:54 AM Dave Hansen wrote: > > > > On 10/18/19 12:44 AM, Michal Hocko wrote: > > > How does this compare to > > > http://lkml.kernel.org/r/1560468577-101178-1-git-send-email-yang.shi@linux.alibaba.com > > > > It's a _bit_ more tied to persistent memory and it appears a bit more > > tied to two tiers rather something arbitrarily deep. They're pretty > > similar conceptually although there are quite a few differences. > > My patches do assume two tiers for now but it is not hard to extend to > multiple tiers. Since it is a RFC so I didn't make it that > complicated. > > However, IMHO I really don't think supporting multiple tiers by making > the migration path configurable to admins or users is a good choice. It's an optional override not a user requirement. > Memory migration caused by compaction or reclaim (not via syscall) > should be transparent to the users, it is the kernel internal > activity. It shouldn't be exposed to the end users. > > I prefer firmware or OS build the migration path personally. The OS can't, it can only trust platform firmware to tell it the memory properties. The BIOS likely gets the tables right most of the time, and the OS can assume they are correct, but when things inevitably go wrong a user override is needed. That override is more usable as an explicit migration path rather than requiring users to manually craft and inject custom ACPI tables. I otherwise do not see the substance behind this objection to a migration path override.