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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 32BA9C433F5 for ; Tue, 29 Mar 2022 22:40:09 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 29D9C8D0002; Tue, 29 Mar 2022 18:40:09 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 24CAA8D0001; Tue, 29 Mar 2022 18:40:09 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 114B58D0002; Tue, 29 Mar 2022 18:40:09 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (relay.hostedemail.com [64.99.140.27]) by kanga.kvack.org (Postfix) with ESMTP id F1B5B8D0001 for ; Tue, 29 Mar 2022 18:40:08 -0400 (EDT) Received: from smtpin02.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id BA29C20571 for ; Tue, 29 Mar 2022 22:40:08 +0000 (UTC) X-FDA: 79298893296.02.0D6BF63 Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by imf06.hostedemail.com (Postfix) with ESMTP id B28FB180015 for ; Tue, 29 Mar 2022 22:40:07 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1648593607; x=1680129607; h=message-id:date:mime-version:to:cc:references:from: subject:in-reply-to:content-transfer-encoding; bh=9ZxjrWRQCn+QQnHcEkTsysVidpslLyjF9+Y3Xn6wT/0=; b=IcioMYBOy2JWGXgSdzrKO2Jzi3oYsT57su+mKx1WMKFDE8EVcHWmKwPT 7fVeFrGNfZemknl/awnD5NMzg0AydV3G7yEN4S93WX9hzg7DRZHwbixHv 7kI8IJGBOthJW75r/wwjM6CdQyNoanW84SXlwwGeGn5oyZwjuaN+5kTBQ kllVoBPB1HvtHTHBvPB/X6gqM9vmkJquPYlJQXYNIgsD4YGGEOAAx/KLK TmbEPCtWBOVQnBE6RIG5iAGVo1x+lLnPOZpl0YMVdUy1tz3AMqLcVIF6a vbrt/s//swX1UBX98f30NYoMunWXWrueJaQ7xJqYmc6EVu0/6REZ8ZLsW g==; X-IronPort-AV: E=McAfee;i="6200,9189,10301"; a="246887074" X-IronPort-AV: E=Sophos;i="5.90,220,1643702400"; d="scan'208";a="246887074" Received: from fmsmga008.fm.intel.com ([10.253.24.58]) by orsmga101.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 29 Mar 2022 15:40:06 -0700 X-IronPort-AV: E=Sophos;i="5.90,220,1643702400"; d="scan'208";a="605075895" Received: from acstuden-mobl.amr.corp.intel.com (HELO [10.209.45.17]) ([10.209.45.17]) by fmsmga008-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 29 Mar 2022 15:40:04 -0700 Message-ID: <3842f49f-d940-333b-74ad-55d1521209cb@intel.com> Date: Tue, 29 Mar 2022 15:40:06 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.5.0 Content-Language: en-US To: Jagdish Gediya Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, akpm@linux-foundation.org, aneesh.kumar@linux.ibm.com, baolin.wang@linux.alibaba.com, dave.hansen@linux.intel.com, ying.huang@intel.com References: <20220329115222.8923-1-jvgediya@linux.ibm.com> <55161160-1084-c81d-d116-00f5bcaa1268@intel.com> From: Dave Hansen Subject: Re: [PATCH] mm: migrate: set demotion targets differently In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Stat-Signature: j4criqkqfo3wopetcr9so9r8domxhmo8 Authentication-Results: imf06.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=IcioMYBO; dmarc=pass (policy=none) header.from=intel.com; spf=none (imf06.hostedemail.com: domain of dave.hansen@intel.com has no SPF policy when checking 134.134.136.20) smtp.mailfrom=dave.hansen@intel.com X-Rspam-User: X-Rspamd-Server: rspam11 X-Rspamd-Queue-Id: B28FB180015 X-HE-Tag: 1648593607-298407 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 3/29/22 09:46, Jagdish Gediya wrote: >> I'd love to see some more information about *why* the current code >> doesn't work. Is it purely a bug or was it mis-designed? > I think the design seems to be intended because as per the comment > in the current code, it was known that there are limits to the node > sharing as a demotion target. Ahh, that makes sense. You've got some slow memory that's not really associated closely enough with an initiator node to be used exclusively for demotions from that node. The original code was really intended for demotions when the system is made up of relatively identical building blocks, like one CPU with two kinds of memory attached. I think what you're doing here makes sense. The only thing I'll say is that, at some point, we need to stop messing with the demotion order that the kernel comes up with. It's not going to be able to handle *everything* perfectly. We're probably not at the point that we should stop enhancing the kernel-generated demotion order, but let's at least keep in mind that we should stop eventually.