Received: by 2002:a5d:9c59:0:0:0:0:0 with SMTP id 25csp2291281iof; Wed, 8 Jun 2022 01:36:05 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxCQmXu9XqVkn2ujlFqRlN+TxAXdBuuXtFkAiVGmxCAcREjQsbfPXVbxUSbJdgglJSoH4s3 X-Received: by 2002:a63:b1e:0:b0:3fd:43d9:5354 with SMTP id 30-20020a630b1e000000b003fd43d95354mr20767394pgl.294.1654677365595; Wed, 08 Jun 2022 01:36:05 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1654677365; cv=none; d=google.com; s=arc-20160816; b=eTKPfMhAtj3lQp/AyvMEWrphj4y68QwIEJO8QOuk/UNk/++WLm1/REmcGdlgsPOBVl TVdZpsmpqsJVMQS+nz4kEwF+6YYcDMNdDEZWe7U5TgE0A1MnMKiAgQFD46WW+lhCC4mn 8TJDWLLxJRbfadVF5WPkEIiPgtJo+acqhJhlkzzue0PIBatfEhv94I5vLF29s1ttwE4H nh15Mu+DTsNXLVvJV2ojTPhEpoYsdTBjFm+jECEj/ASb4kBCN7wREkmrFQahSkorMEEF eMSeEyXpmFAOumnpEP56hq4tJtemjhG8Ru3LCIJ9YQGSoZqf5f7LSM3Qp8SQ19/tVxLL jkvg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:date:cc:to:from:subject :message-id:dkim-signature; bh=WYJZLjGpf6R/Zi+oL7EzI3q8gGPy3ogMUPbl1d2p1Zo=; b=O1oZbn3eGhaXdIIf4IXhs6FrEgCkGu3r69Q+puU7s3+lcsgIcU0oUGyaAv2gpxR9Yb ItU0HZUOBeCHaLueeYrjly2cUU+I1IBekWA4cszwxveD7lLpAZmgt/VAFpySk0oRGxuV z/0qwydVw9MXwXb6ufZdbdLxzXxJ7pF5z8GadE7oAblvfTVV0hNDutfgWKVyyZNYymaZ SS4wqmVMjRU5mV81fQ/NBxLQNgT7m4SQnsCm4akFYVFuSysw6bx8y6MWH0grjvx1U1TK XgJ77qAHze0BxTVXrPjWeArDgvioiBRdEY5hl1nbbEj09Q4MNoBKJDQSV4EctCVIOMmC 9cTg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=TM9gFjFc; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 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 lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [23.128.96.19]) by mx.google.com with ESMTPS id m18-20020a170902bb9200b0016362b01d1fsi23788431pls.600.2022.06.08.01.36.05 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 08 Jun 2022 01:36:05 -0700 (PDT) Received-SPF: softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) client-ip=23.128.96.19; Authentication-Results: mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=TM9gFjFc; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 3FDF421E308; Wed, 8 Jun 2022 01:01:39 -0700 (PDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S240310AbiFHHEE (ORCPT + 99 others); Wed, 8 Jun 2022 03:04:04 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:53220 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1354198AbiFHGT0 (ORCPT ); Wed, 8 Jun 2022 02:19:26 -0400 Received: from mga06.intel.com (mga06b.intel.com [134.134.136.31]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B83571483D4 for ; Tue, 7 Jun 2022 23:06:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1654668412; x=1686204412; h=message-id:subject:from:to:cc:date:in-reply-to: references:mime-version:content-transfer-encoding; bh=uVvtxf05SKDsySGKn1SFfLh2lQyAvaiLbpKHel9kyOU=; b=TM9gFjFc9tekQ9LjZSlulKIGxKcj2GpCEdplyybMJxK8MXfvNTXMnykc CxwGeJod+HnaP+uWPc9hiwK8j8FlgRpx1LnxfbGkP8g0Q6cxO5HV4gCkN ezdYfuG/oravshYTE4/fwfI9Zr16cRZBIdF1nCoSgZ0nw6WoIvcrJ9TEg i+WGDvafnPWxoN5ReMaF9rSe7IXMMUF0rS+zh3mH+uMNoqD99E4k7uOqI oKVBA1oFaW8DcnopdD++OnB0LeN+d8g3HPcNXxHdoBDfmlhVCARHZjpiD 1AUuPC1TYsjB39sxKevde95XtIMYrkCj6F5jddvEm19OfkcopT2wjX8ES Q==; X-IronPort-AV: E=McAfee;i="6400,9594,10371"; a="338551267" X-IronPort-AV: E=Sophos;i="5.91,285,1647327600"; d="scan'208";a="338551267" Received: from fmsmga006.fm.intel.com ([10.253.24.20]) by orsmga104.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 07 Jun 2022 23:06:27 -0700 X-IronPort-AV: E=Sophos;i="5.91,285,1647327600"; d="scan'208";a="826760381" Received: from xding11-mobl.ccr.corp.intel.com ([10.254.214.239]) by fmsmga006-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 07 Jun 2022 23:06:22 -0700 Message-ID: <6d72cab6badb003d996eaf5454939e552d2ba67d.camel@intel.com> Subject: Re: [PATCH v5 1/9] mm/demotion: Add support for explicit memory tiers From: Ying Huang To: Aneesh Kumar K V , Tim Chen , linux-mm@kvack.org, akpm@linux-foundation.org Cc: Wei Xu , Greg Thelen , Yang Shi , Davidlohr Bueso , Tim C Chen , Brice Goglin , Michal Hocko , Linux Kernel Mailing List , Hesham Almatary , Dave Hansen , Jonathan Cameron , Alistair Popple , Dan Williams , Feng Tang , Jagdish Gediya , Baolin Wang , David Rientjes Date: Wed, 08 Jun 2022 14:06:20 +0800 In-Reply-To: <8a42d52c-6275-4798-19c0-dfc530c04b0e@linux.ibm.com> References: <20220603134237.131362-1-aneesh.kumar@linux.ibm.com> <20220603134237.131362-2-aneesh.kumar@linux.ibm.com> <92649c9a6e0b6931b34aeaaf22c0a1e874484b7f.camel@linux.intel.com> <8a42d52c-6275-4798-19c0-dfc530c04b0e@linux.ibm.com> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.38.3-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-3.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RDNS_NONE,SPF_HELO_NONE,T_SCC_BODY_TEXT_LINE autolearn=unavailable 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 On Wed, 2022-06-08 at 10:00 +0530, Aneesh Kumar K V wrote: > On 6/8/22 12:13 AM, Tim Chen wrote: > > On Fri, 2022-06-03 at 19:12 +0530, Aneesh Kumar K.V wrote: > > > > > > > > > The nodes which are part of a specific memory tier can be listed > > > via > > > /sys/devices/system/memtier/memtierN/nodelist > > > > > > "Rank" is an opaque value. Its absolute value doesn't have any > > > special meaning. But the rank values of different memtiers can be > > > compared with each other to determine the memory tier order. > > > > > > For example, if we have 3 memtiers: memtier0, memtier1, memiter2, and > > > their rank values are 300, 200, 100, then the memory tier order is: > > > memtier0 -> memtier2 -> memtier1, > > > > Why is memtier2 (rank 100) higher than memtier1 (rank 200)? Seems like > > the order should be memtier0 -> memtier1 -> memtier2? > >                      (rank 300) (rank 200) (rank 100) > > > > > where memtier0 is the highest tier > > > and memtier1 is the lowest tier. > > > > I think memtier2 is the lowest as it has the lowest rank value. > > > typo error. Will fix that in the next update > > > > > > > The rank value of each memtier should be unique. > > > > > > > > > + > > > +static void memory_tier_device_release(struct device *dev) > > > +{ > > > + struct memory_tier *tier = to_memory_tier(dev); > > > + > > > > Do we need some ref counts on memory_tier? > > If there is another device still using the same memtier, > > free below could cause problem. > > > > > + kfree(tier); > > > +} > > > + > > > > > ... > > > +static struct memory_tier *register_memory_tier(unsigned int tier) > > > +{ > > > + int error; > > > + struct memory_tier *memtier; > > > + > > > + if (tier >= MAX_MEMORY_TIERS) > > > + return NULL; > > > + > > > + memtier = kzalloc(sizeof(struct memory_tier), GFP_KERNEL); > > > + if (!memtier) > > > + return NULL; > > > + > > > + memtier->dev.id = tier; > > > + memtier->rank = get_rank_from_tier(tier); > > > + memtier->dev.bus = &memory_tier_subsys; > > > + memtier->dev.release = memory_tier_device_release; > > > + memtier->dev.groups = memory_tier_dev_groups; > > > + > > > > Should you take the mem_tier_lock before you insert to > > memtier-list? > > > Both register_memory_tier and unregister_memory_tier get called with > memory_tier_lock held. Then please add locking requirements to the comments above these functions. Best Regards, Huang, Ying > > > > > + insert_memory_tier(memtier); > > > + > > > + error = device_register(&memtier->dev); > > > + if (error) { > > > + list_del(&memtier->list); > > > + put_device(&memtier->dev); > > > + return NULL; > > > + } > > > + return memtier; > > > +} > > > + > > > +__maybe_unused // temporay to prevent warnings during bisects > > > +static void unregister_memory_tier(struct memory_tier *memtier) > > > +{ > > > > I think we should take mem_tier_lock before modifying memtier->list. > > > > unregister_memory_tier get called with memory_tier_lock held. > > > > + list_del(&memtier->list); > > > + device_unregister(&memtier->dev); > > > +} > > > + > > > > > -aneesh