Received: by 2002:a05:6a10:5bc5:0:0:0:0 with SMTP id os5csp192695pxb; Fri, 15 Oct 2021 03:41:19 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwww6PVb6lAcbP6QWMWrB0EYgcYRj3mPyhbyFmQjgbm+LMbuR2Z5I+Yk1Je6Y4DEDHzHMGe X-Received: by 2002:aa7:8004:0:b0:44c:8f3d:40e9 with SMTP id j4-20020aa78004000000b0044c8f3d40e9mr11212674pfi.49.1634294478793; Fri, 15 Oct 2021 03:41:18 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1634294478; cv=none; d=google.com; s=arc-20160816; b=ZXAN7hsTPWkc9zZhXHtrPEOnioON1QRYffmvtLrDv00dY59NndJfYAXWhWWa8aCItX K0jgQsdqEttpG/ZM6d4vl82/fiLDZvo9qYl3nGLi3SyYZuOpyEwONOcRVsT9JXxtfzNG aQH0aUngF/z8AOK57aJlgSQZa/EeFW6de1v63h6aad1fSMmt3l+Vcq2jPHLfyeRp0SI6 /QJs3m/bI/u15AdWjSp0IvFXkuTLtSvr0phQ/gHfO3QG3L16ENMLiMMhBoUOzkh9Hzle lPrZJjP/RNRorgCeDxAzpiwC3OhFvOGAt5/pEgYunhVPs/vWBMZHNasXN9fXeBopXE5b y73A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:user-agent:message-id:in-reply-to :date:references:subject:cc:to:from; bh=DFkWddYf2sOz1BURMiqlAvAKun3cJFSzPYMLzzxRRYg=; b=sF88Eg+liPzGIYLWPK8KD1TOVOOKTLK9i2nzPoDFSm91R4tkuGNZxUe0W2iPKSwSyB HBRZLLASlJUD9abaI/pCBWOecJwjRVa/IwRG21932j0DbTS0zax8sGko+vljO+N5jT93 xZhOZkP9tgpXgmR44ph1AWvxuUeuWPwl3fCpiYq68g5pDJGc3zgtBdRlOBgwnrJ/S8SM hdgAoLKJm3kgjE8pThPIjUrbhRpUgZGXm4+MecvgeG6kcPN+c76dZEtKpQOY3Ik5jt4S wMuesREvZksir7UNEnbviabmLaGcViOCryvdZDCo08u70pAUnbV0QEPskpE7cmbXJqES e3Hg== 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 d27si9225463pgd.29.2021.10.15.03.40.54; Fri, 15 Oct 2021 03:41:18 -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 S233065AbhJOBoa (ORCPT + 99 others); Thu, 14 Oct 2021 21:44:30 -0400 Received: from mga06.intel.com ([134.134.136.31]:18332 "EHLO mga06.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229832AbhJOBo3 (ORCPT ); Thu, 14 Oct 2021 21:44:29 -0400 X-IronPort-AV: E=McAfee;i="6200,9189,10137"; a="288695890" X-IronPort-AV: E=Sophos;i="5.85,374,1624345200"; d="scan'208";a="288695890" Received: from orsmga004.jf.intel.com ([10.7.209.38]) by orsmga104.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 14 Oct 2021 18:42:23 -0700 X-IronPort-AV: E=Sophos;i="5.85,374,1624345200"; d="scan'208";a="592827275" Received: from yhuang6-desk2.sh.intel.com (HELO yhuang6-desk2.ccr.corp.intel.com) ([10.239.159.119]) by orsmga004-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 14 Oct 2021 18:42:21 -0700 From: "Huang, Ying" To: Yang Shi Cc: dave.hansen@linux.intel.com, akpm@linux-foundation.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] mm: migrate: make demotion knob depend on migration References: <20211015005559.246709-1-shy828301@gmail.com> Date: Fri, 15 Oct 2021 09:42:19 +0800 In-Reply-To: <20211015005559.246709-1-shy828301@gmail.com> (Yang Shi's message of "Thu, 14 Oct 2021 17:55:59 -0700") Message-ID: <875ytznjwk.fsf@yhuang6-desk2.ccr.corp.intel.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=ascii Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Yang Shi writes: > The memory demotion needs to call migrate_pages() to do the jobs. And > it is controlled by a knob, however, the knob doesn't depend on > CONFIG_MIGRATION. The knob could be truned on even though MIGRATION is > disabled, this will not cause any crash since migrate_pages() would just > return -ENOSYS. But it is definitely not optimal to go through demotion > path then retry regular swap every time. > > And it doesn't make too much sense to have the knob visible to the users > when !MIGRATION. Move the related code from mempolicy.[h|c] to migrate.[h|c]. Sounds reasonable to me. Thanks! > Signed-off-by: Yang Shi Acked-by: "Huang, Ying" Best Regards, Huang, Ying