Received: by 2002:a05:6358:701b:b0:131:369:b2a3 with SMTP id 27csp4147242rwo; Tue, 25 Jul 2023 01:02:28 -0700 (PDT) X-Google-Smtp-Source: APBJJlH4iR6ybv1A84yMuvxc+UIvkFdhZPy6Uq6BYL9xlXvMhDYgYxdW7fdGTFxwp0742MZ3GMXm X-Received: by 2002:aa7:d882:0:b0:522:1eab:e466 with SMTP id u2-20020aa7d882000000b005221eabe466mr6181070edq.28.1690272148316; Tue, 25 Jul 2023 01:02:28 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1690272148; cv=none; d=google.com; s=arc-20160816; b=VMqtefTHdXYrHDChNay4mhlt9jlQ8FIlQUV1e6kczVaYBaW89y+s/ldDxQOUuKfd1v 0J1rBwgRkG8eITY2ETyFnxnqbdSqQQ/Yb1L+vh5iciled6NtFDH9p8KRKPQwI69T8fKA rEnLZqpTu3033HQrtV3tklhrhXF8aC9auDnXiyJUQK9eIy4JM69v9+sCiy38pA7Ue39i lC74z0j/rkBmH5WGSbmPAZRm7xpATCTaDiJo3musABYGGEKRdftsJNM6VWT9OfsFRBrI YBL7ICB/ApVoKxDo1Z/jYZIVVwB4X8s7iCeHnXIOI8QqKXrJQDWJVu23r9O4JiOZppoa 8fsg== 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:dkim-signature; bh=MkZL/TN9QrGmZ6+6cS//HvwqOl7bVQib2URvKnX7jHA=; fh=njrOnqy+uOC/eywmsVAmwO0A7biLXjf73x50f7/uewA=; b=cWo19ghjZX160z/7vj7UHYLsy6ENWMTJeuzExLSP0kylin3pPPU9fw0OYgIVfQ2GoT Bp0pUW/3n1vLCUnFqmTODQIt3hFqbK2L25cRa1gUFndPWgn/V6cKWON1xgo3b27iW4wb wm9c9cSgKtwgQ8mnR7T1CFNZOUm5nBSqytm7jexYKiyMTSL/E2KDBwZ+HLCcuML97eVx g6L4PSMnKrL9PYimuAh9yQbPPrIyfVsSJuVO2T8y0t+p786h1/MuvnEy829mq83wM7PQ Fmw9DatlgN7AnK+wm2n9OsgvIzVicv8jadVPouDoorF3t4wAWnJvl8HAo6UQqEQ8+2OC o9fQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=mV4V4BRx; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id x3-20020aa7d383000000b0052227f13c0csi3737179edq.394.2023.07.25.01.02.02; Tue, 25 Jul 2023 01:02:28 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=mV4V4BRx; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231182AbjGYHE3 (ORCPT + 99 others); Tue, 25 Jul 2023 03:04:29 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:34678 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230331AbjGYHE0 (ORCPT ); Tue, 25 Jul 2023 03:04:26 -0400 Received: from mga06.intel.com (mga06b.intel.com [134.134.136.31]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id F0707E66; Tue, 25 Jul 2023 00:04:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1690268664; x=1721804664; h=from:to:cc:subject:references:date:in-reply-to: message-id:mime-version; bh=z+bpg4f1Gpa03QOb988ceLF/hGx+yZITJmrLI5YMZc0=; b=mV4V4BRx+RTi1uEMSg3bPKnwinSmNjEmL4ORRzD0oEI+XnXZDHuQ8BFD 46jz+mEo3Re7E6aEmJVZdi1qwbNiWFHrrrwHo7kvMWsnPDQkIEQ7jFlZC RdfuC/4MPWslsuywufuqBSarNbXGn3UGoIZYDCV+Q757T/SXA4pzxz2DL sSgyXpMThRm7UtojdvVjxJBbN9jO72/hzHSp1WNvvXxO0W70uWIUi4Irh nXQxSYS8CDzdV4TdRPFAqzhFylObFDA2xYxISPs5GfD6sWCTpXbOPAl4g 6bP5blVvhMm+8xCu6k6gTlOZI467xxSJze/2PyM+U5F0kyN7ddRtx7H+U w==; X-IronPort-AV: E=McAfee;i="6600,9927,10781"; a="431438957" X-IronPort-AV: E=Sophos;i="6.01,230,1684825200"; d="scan'208";a="431438957" Received: from orsmga007.jf.intel.com ([10.7.209.58]) by orsmga104.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 25 Jul 2023 00:04:23 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10781"; a="719946762" X-IronPort-AV: E=Sophos;i="6.01,230,1684825200"; d="scan'208";a="719946762" Received: from yhuang6-desk2.sh.intel.com (HELO yhuang6-desk2.ccr.corp.intel.com) ([10.238.208.55]) by orsmga007-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 25 Jul 2023 00:04:19 -0700 From: "Huang, Ying" To: Alistair Popple Cc: Andrew Morton , , , , , , "Aneesh Kumar K . V" , Wei Xu , Dan Williams , Dave Hansen , "Davidlohr Bueso" , Johannes Weiner , "Jonathan Cameron" , Michal Hocko , Yang Shi , Rafael J Wysocki Subject: Re: [PATCH RESEND 4/4] dax, kmem: calculate abstract distance with general interface References: <20230721012932.190742-1-ying.huang@intel.com> <20230721012932.190742-5-ying.huang@intel.com> <87edkwznsf.fsf@nvdebian.thelocal> Date: Tue, 25 Jul 2023 15:02:42 +0800 In-Reply-To: <87edkwznsf.fsf@nvdebian.thelocal> (Alistair Popple's message of "Tue, 25 Jul 2023 13:11:12 +1000") Message-ID: <87cz0gxylp.fsf@yhuang6-desk2.ccr.corp.intel.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=ascii X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_MED, SPF_HELO_NONE,SPF_NONE,T_SCC_BODY_TEXT_LINE,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Alistair Popple writes: > Huang Ying writes: > >> Previously, a fixed abstract distance MEMTIER_DEFAULT_DAX_ADISTANCE is >> used for slow memory type in kmem driver. This limits the usage of >> kmem driver, for example, it cannot be used for HBM (high bandwidth >> memory). >> >> So, we use the general abstract distance calculation mechanism in kmem >> drivers to get more accurate abstract distance on systems with proper >> support. The original MEMTIER_DEFAULT_DAX_ADISTANCE is used as >> fallback only. >> >> Now, multiple memory types may be managed by kmem. These memory types >> are put into the "kmem_memory_types" list and protected by >> kmem_memory_type_lock. > > See below but I wonder if kmem_memory_types could be a common helper > rather than kdax specific? > >> Signed-off-by: "Huang, Ying" >> Cc: Aneesh Kumar K.V >> Cc: Wei Xu >> Cc: Alistair Popple >> Cc: Dan Williams >> Cc: Dave Hansen >> Cc: Davidlohr Bueso >> Cc: Johannes Weiner >> Cc: Jonathan Cameron >> Cc: Michal Hocko >> Cc: Yang Shi >> Cc: Rafael J Wysocki >> --- >> drivers/dax/kmem.c | 54 +++++++++++++++++++++++++++--------- >> include/linux/memory-tiers.h | 2 ++ >> mm/memory-tiers.c | 2 +- >> 3 files changed, 44 insertions(+), 14 deletions(-) >> >> diff --git a/drivers/dax/kmem.c b/drivers/dax/kmem.c >> index 898ca9505754..837165037231 100644 >> --- a/drivers/dax/kmem.c >> +++ b/drivers/dax/kmem.c >> @@ -49,14 +49,40 @@ struct dax_kmem_data { >> struct resource *res[]; >> }; >> >> -static struct memory_dev_type *dax_slowmem_type; >> +static DEFINE_MUTEX(kmem_memory_type_lock); >> +static LIST_HEAD(kmem_memory_types); >> + >> +static struct memory_dev_type *kmem_find_alloc_memorty_type(int adist) >> +{ >> + bool found = false; >> + struct memory_dev_type *mtype; >> + >> + mutex_lock(&kmem_memory_type_lock); >> + list_for_each_entry(mtype, &kmem_memory_types, list) { >> + if (mtype->adistance == adist) { >> + found = true; >> + break; >> + } >> + } >> + if (!found) { >> + mtype = alloc_memory_type(adist); >> + if (!IS_ERR(mtype)) >> + list_add(&mtype->list, &kmem_memory_types); >> + } >> + mutex_unlock(&kmem_memory_type_lock); >> + >> + return mtype; >> +} >> + >> static int dev_dax_kmem_probe(struct dev_dax *dev_dax) >> { >> struct device *dev = &dev_dax->dev; >> unsigned long total_len = 0; >> struct dax_kmem_data *data; >> + struct memory_dev_type *mtype; >> int i, rc, mapped = 0; >> int numa_node; >> + int adist = MEMTIER_DEFAULT_DAX_ADISTANCE; >> >> /* >> * Ensure good NUMA information for the persistent memory. >> @@ -71,6 +97,11 @@ static int dev_dax_kmem_probe(struct dev_dax *dev_dax) >> return -EINVAL; >> } >> >> + mt_calc_adistance(numa_node, &adist); >> + mtype = kmem_find_alloc_memorty_type(adist); >> + if (IS_ERR(mtype)) >> + return PTR_ERR(mtype); >> + > > I wrote my own quick and dirty module to test this and wrote basically > the same code sequence. > > I notice your using a list of memory types here though. I think it would > be nice to have a common helper that other users could call to do the > mt_calc_adistance() / kmem_find_alloc_memory_type() / > init_node_memory_type() sequence and cleanup as my naive approach would > result in a new memory_dev_type per device even though adist might be > the same. A common helper would make it easy to de-dup those. If it's useful, we can move kmem_find_alloc_memory_type() to memory-tier.c after some revision. But I tend to move it after we have the second user. What do you think about that? -- Best Regards, Huang, Ying >> for (i = 0; i < dev_dax->nr_range; i++) { >> struct range range; >> >> @@ -88,7 +119,7 @@ static int dev_dax_kmem_probe(struct dev_dax *dev_dax) >> return -EINVAL; >> } >> >> - init_node_memory_type(numa_node, dax_slowmem_type); >> + init_node_memory_type(numa_node, mtype); >> >> rc = -ENOMEM; >> data = kzalloc(struct_size(data, res, dev_dax->nr_range), GFP_KERNEL); >> @@ -167,7 +198,7 @@ static int dev_dax_kmem_probe(struct dev_dax *dev_dax) >> err_res_name: >> kfree(data); >> err_dax_kmem_data: >> - clear_node_memory_type(numa_node, dax_slowmem_type); >> + clear_node_memory_type(numa_node, mtype); >> return rc; >> } >> >> @@ -219,7 +250,7 @@ static void dev_dax_kmem_remove(struct dev_dax *dev_dax) >> * for that. This implies this reference will be around >> * till next reboot. >> */ >> - clear_node_memory_type(node, dax_slowmem_type); >> + clear_node_memory_type(node, NULL); >> } >> } >> #else >> @@ -251,12 +282,6 @@ static int __init dax_kmem_init(void) >> if (!kmem_name) >> return -ENOMEM; >> >> - dax_slowmem_type = alloc_memory_type(MEMTIER_DEFAULT_DAX_ADISTANCE); >> - if (IS_ERR(dax_slowmem_type)) { >> - rc = PTR_ERR(dax_slowmem_type); >> - goto err_dax_slowmem_type; >> - } >> - >> rc = dax_driver_register(&device_dax_kmem_driver); >> if (rc) >> goto error_dax_driver; >> @@ -264,18 +289,21 @@ static int __init dax_kmem_init(void) >> return rc; >> >> error_dax_driver: >> - destroy_memory_type(dax_slowmem_type); >> -err_dax_slowmem_type: >> kfree_const(kmem_name); >> return rc; >> } >> >> static void __exit dax_kmem_exit(void) >> { >> + struct memory_dev_type *mtype, *mtn; >> + >> dax_driver_unregister(&device_dax_kmem_driver); >> if (!any_hotremove_failed) >> kfree_const(kmem_name); >> - destroy_memory_type(dax_slowmem_type); >> + list_for_each_entry_safe(mtype, mtn, &kmem_memory_types, list) { >> + list_del(&mtype->list); >> + destroy_memory_type(mtype); >> + } >> } >> >> MODULE_AUTHOR("Intel Corporation"); >> diff --git a/include/linux/memory-tiers.h b/include/linux/memory-tiers.h >> index 9377239c8d34..aca22220cb5c 100644 >> --- a/include/linux/memory-tiers.h >> +++ b/include/linux/memory-tiers.h >> @@ -24,6 +24,8 @@ struct memory_tier; >> struct memory_dev_type { >> /* list of memory types that are part of same tier as this type */ >> struct list_head tier_sibiling; >> + /* list of memory types that are managed by one driver */ >> + struct list_head list; >> /* abstract distance for this specific memory type */ >> int adistance; >> /* Nodes of same abstract distance */ >> diff --git a/mm/memory-tiers.c b/mm/memory-tiers.c >> index 9a734ef2edfb..38005c60fa2d 100644 >> --- a/mm/memory-tiers.c >> +++ b/mm/memory-tiers.c >> @@ -581,7 +581,7 @@ EXPORT_SYMBOL_GPL(init_node_memory_type); >> void clear_node_memory_type(int node, struct memory_dev_type *memtype) >> { >> mutex_lock(&memory_tier_lock); >> - if (node_memory_types[node].memtype == memtype) >> + if (node_memory_types[node].memtype == memtype || !memtype) >> node_memory_types[node].map_count--; >> /* >> * If we umapped all the attached devices to this node,