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 C9EC2CCA47B for ; Wed, 8 Jun 2022 06:10:20 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 63A906B0075; Wed, 8 Jun 2022 02:10:20 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 5E7FF6B0078; Wed, 8 Jun 2022 02:10:20 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 48A6C8D0001; Wed, 8 Jun 2022 02:10:20 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 3A62D6B0075 for ; Wed, 8 Jun 2022 02:10:20 -0400 (EDT) Received: from smtpin11.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 147D43467F for ; Wed, 8 Jun 2022 06:10:20 +0000 (UTC) X-FDA: 79554043800.11.5B2DF51 Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by imf07.hostedemail.com (Postfix) with ESMTP id 2A6A040004 for ; Wed, 8 Jun 2022 06:10:18 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1654668619; x=1686204619; h=message-id:subject:from:to:cc:date:in-reply-to: references:mime-version:content-transfer-encoding; bh=wSpGqlJOs7netwFupcWWwUUiv8vP2SDhvcyzrkviMpI=; b=TZE5qTGmsLlxAQCbw9NePNzk+YeNrioDWH/eZiYFBRyB/LjjJY10cWaa 7CRa+6HHpr9K+rgaS5FI8e2uXHRjJjFstPT6lSoKYcIZDFxVPb2CwUI7K QKQoDA9YCN0pPD8k3gtUgJtNhPjga8T1m378nXHIfhWoG/412y/UdA2+E 1x27DAqxfBdbDiWD2nJdGP5hkTzxhczVAY7VVedjfU7wdiDbWVpIr7QtP XQtxbO7auOB1V+BdCnXpAp2NIDdn+qYbc9x/KcOaNsPgUMufKA4iv4jGb 9FT9NiRgDcXZHOkFWldk2FhTRYRDd7jfiCIHURHwQZXoO7b7+xRGHp5Be g==; X-IronPort-AV: E=McAfee;i="6400,9594,10371"; a="277602573" X-IronPort-AV: E=Sophos;i="5.91,285,1647327600"; d="scan'208";a="277602573" Received: from fmsmga006.fm.intel.com ([10.253.24.20]) by orsmga102.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 07 Jun 2022 23:10:09 -0700 X-IronPort-AV: E=Sophos;i="5.91,285,1647327600"; d="scan'208";a="826761637" 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:10:04 -0700 Message-ID: <71a0734bc918b7a6cf75b0b411b7b6a87f0bda92.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:10:02 +0800 In-Reply-To: References: <20220603134237.131362-1-aneesh.kumar@linux.ibm.com> <20220603134237.131362-2-aneesh.kumar@linux.ibm.com> <92649c9a6e0b6931b34aeaaf22c0a1e874484b7f.camel@linux.intel.com> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.38.3-1 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Stat-Signature: pp4nec5yar4biiajgmxcf41npprxrk3q Authentication-Results: imf07.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=TZE5qTGm; dmarc=pass (policy=none) header.from=intel.com; spf=none (imf07.hostedemail.com: domain of ying.huang@intel.com has no SPF policy when checking 134.134.136.24) smtp.mailfrom=ying.huang@intel.com X-Rspam-User: X-Rspamd-Server: rspam11 X-Rspamd-Queue-Id: 2A6A040004 X-HE-Tag: 1654668618-188163 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 Wed, 2022-06-08 at 10:07 +0530, Aneesh Kumar K V wrote: > On 6/8/22 12:13 AM, Tim Chen wrote: > ... > > > > > > > + > > > +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); > > > +} > > > + > > > > > ... > > The lifecycle of the memory_tier struct is tied to the sysfs device life > time. ie, memory_tier_device_relese get called only after the last > reference on that sysfs dev object is released. Hence we can be sure > there is no userspace that is keeping one of the memtier related sysfs > file open. > > W.r.t other memory device sharing the same memtier, we unregister the > sysfs device only when the memory tier nodelist is empty. That is no > memory device is present in this memory tier. memory_tier isn't only used by user space. It is used inside kernel too. If some kernel code get a pointer to struct memory_tier, we need to guarantee the pointer will not be freed under us. And as Tim pointed out, we need to use it in hot path (for statistics), so some kind of rcu lock may be good. Best Regards, Huang, Ying