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 B3861C6FA81 for ; Fri, 2 Sep 2022 07:58:11 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id F2D4F800CD; Fri, 2 Sep 2022 03:58:10 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id EDC668008D; Fri, 2 Sep 2022 03:58:10 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id DCB44800CD; Fri, 2 Sep 2022 03:58:10 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id CE94A8008D for ; Fri, 2 Sep 2022 03:58:10 -0400 (EDT) Received: from smtpin30.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 996938040E for ; Fri, 2 Sep 2022 07:58:10 +0000 (UTC) X-FDA: 79866392340.30.CD33059 Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by imf10.hostedemail.com (Postfix) with ESMTP id 5AD3CC004B for ; Fri, 2 Sep 2022 07:58:09 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1662105489; x=1693641489; h=from:to:cc:subject:in-reply-to:references:date: message-id:mime-version; bh=U+sckmWxu/dh7LzjzffyvQqItsRKsl7L7Kdq5ogbtnY=; b=Rze4bVeerMt0ZH4Yjb+GB6JnRVeDwyhhIpyXmpxXj2e03TyNsYYBYhE6 oqjMt6FGEc4LOd6BZ9+GgTPDjQFzpM4817CuLHdtvjbn0ueV9t2nJI6sX Q/xzRSwNAO+yO9tiNZrvWlnQuBRKC5ExIBJlJurF2ZpwzaZ3rVGtjnnOA xu12Mg9aodhROBgeaqS+tHSCNbeMZmcFMeBrjECs8WZ9GJ6frk4syZZOM rbJ0cM79LCI9nkQtzkvsAs39LamsMOmatSYGaIq9b5AY36EojgoAbdtZC XZ3OUFCGP9dE8tuw5G4ESnIuZBXlltde9/1Bn0khFh+KJFROajXnrj/eg A==; X-IronPort-AV: E=McAfee;i="6500,9779,10457"; a="295932458" X-IronPort-AV: E=Sophos;i="5.93,283,1654585200"; d="scan'208";a="295932458" Received: from orsmga006.jf.intel.com ([10.7.209.51]) by fmsmga103.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 02 Sep 2022 00:58:07 -0700 X-IronPort-AV: E=Sophos;i="5.93,283,1654585200"; d="scan'208";a="589983425" Received: from yhuang6-desk2.sh.intel.com (HELO yhuang6-desk2.ccr.corp.intel.com) ([10.238.208.55]) by orsmga006-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 02 Sep 2022 00:58:02 -0700 From: "Huang, Ying" To: Wei Xu , Aneesh Kumar K V , Johannes Weiner Cc: Linux MM , Andrew Morton , Yang Shi , Davidlohr Bueso , Tim C Chen , Michal Hocko , Linux Kernel Mailing List , Hesham Almatary , Dave Hansen , Jonathan Cameron , Alistair Popple , Dan Williams , jvgediya.oss@gmail.com, Bharata B Rao , Greg Thelen , Greg Kroah-Hartman , "Rafael J. Wysocki" Subject: Re: [PATCH v3 updated] mm/demotion: Expose memory tier details via sysfs In-Reply-To: (Wei Xu's message of "Fri, 2 Sep 2022 00:02:05 -0700") References: <20220830081736.119281-1-aneesh.kumar@linux.ibm.com> <87tu5rzigc.fsf@yhuang6-desk2.ccr.corp.intel.com> <87pmgezkhp.fsf@yhuang6-desk2.ccr.corp.intel.com> <87fshaz63h.fsf@yhuang6-desk2.ccr.corp.intel.com> <698120ce-d4df-3d13-dea9-a8f5c298783c@linux.ibm.com> <87bkryz4nh.fsf@yhuang6-desk2.ccr.corp.intel.com> <2b4ddc45-74ae-27df-d973-6724f61f4e18@linux.ibm.com> <877d2mz3c1.fsf@yhuang6-desk2.ccr.corp.intel.com> <45488760-02b5-115b-c16d-5219303f2f33@linux.ibm.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux) Date: Fri, 02 Sep 2022 15:57:53 +0800 Message-ID: <871qsuyzr2.fsf@yhuang6-desk2.ccr.corp.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ascii ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1662105490; a=rsa-sha256; cv=none; b=ycsSQarWFYtDkaMv7SbkidtDUJJum+8UTxWUiEoPKQ/SlewfuNEVS1yqO+d4uEfJmn9gnb kXOQWoaQYiFkeFB92wPKmKsMA2fXTFObCt4pwKya4cpcLiqCKzFSlL5csy1ZTiI7oJI8qc JyqFmxEq79ROwaL4usEDi+X1zBXpc38= ARC-Authentication-Results: i=1; imf10.hostedemail.com; dkim=none ("invalid DKIM record") header.d=intel.com header.s=Intel header.b=Rze4bVee; spf=pass (imf10.hostedemail.com: domain of ying.huang@intel.com designates 192.55.52.115 as permitted sender) smtp.mailfrom=ying.huang@intel.com; dmarc=pass (policy=none) header.from=intel.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1662105490; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=NbzGEJGTLFMuXO9XSvdyYKCCaUgqZ9m/bPSjE/6xFXk=; b=P7zzCoSvPIvcfn+p4KQw45LVmqS2dXgSdC5yQ+JEY60NYGb6nDDlcI0VAiVAj2oLo920He S96TKm/gH+2l5HTLQsvIYxangIiK+V4t8nLUFcqDlQu8MhmMkvaZwg0lRG91d/nOM+ceqx oH629DQ+IZXNqPZuvYtYI8oFJYUQzYA= Authentication-Results: imf10.hostedemail.com; dkim=none ("invalid DKIM record") header.d=intel.com header.s=Intel header.b=Rze4bVee; spf=pass (imf10.hostedemail.com: domain of ying.huang@intel.com designates 192.55.52.115 as permitted sender) smtp.mailfrom=ying.huang@intel.com; dmarc=pass (policy=none) header.from=intel.com X-Rspam-User: X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: 5AD3CC004B X-Stat-Signature: 77suptwdrxabagz7kbcc6toqfdt8mctx X-HE-Tag: 1662105489-960134 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: Wei Xu writes: > On Thu, Sep 1, 2022 at 11:44 PM Aneesh Kumar K V > wrote: >> >> On 9/2/22 12:10 PM, Huang, Ying wrote: >> > Aneesh Kumar K V writes: >> > >> >> On 9/2/22 11:42 AM, Huang, Ying wrote: >> >>> Aneesh Kumar K V writes: >> >>> >> >>>> On 9/2/22 11:10 AM, Huang, Ying wrote: >> >>>>> Aneesh Kumar K V writes: >> >>>>> >> >>>>>> On 9/2/22 10:39 AM, Wei Xu wrote: >> >>>>>>> On Thu, Sep 1, 2022 at 5:33 PM Huang, Ying wrote: >> >>>>>>>> >> >>>>>>>> Aneesh Kumar K V writes: >> >>>>>>>> >> >>>>>>>>> On 9/1/22 12:31 PM, Huang, Ying wrote: >> >>>>>>>>>> "Aneesh Kumar K.V" writes: >> >>>>>>>>>> >> >>>>>>>>>>> This patch adds /sys/devices/virtual/memory_tiering/ where all memory tier >> >>>>>>>>>>> related details can be found. All allocated memory tiers will be listed >> >>>>>>>>>>> there as /sys/devices/virtual/memory_tiering/memory_tierN/ >> >>>>>>>>>>> >> >>>>>>>>>>> The nodes which are part of a specific memory tier can be listed via >> >>>>>>>>>>> /sys/devices/virtual/memory_tiering/memory_tierN/nodes >> >>>>>>>>>> >> >>>>>>>>>> I think "memory_tier" is a better subsystem/bus name than >> >>>>>>>>>> memory_tiering. Because we have a set of memory_tierN devices inside. >> >>>>>>>>>> "memory_tier" sounds more natural. I know this is subjective, just my >> >>>>>>>>>> preference. >> >>>>>>>>>> >> >>>>>> >> >>>>>> >> >>>>>> I missed replying to this earlier. I will keep memory_tiering as subsystem name in v4 >> >>>>>> because we would want it to a susbsystem where all memory tiering related details can be found >> >>>>>> including memory type in the future. This is as per discussion >> >>>>>> >> >>>>>> https://lore.kernel.org/linux-mm/CAAPL-u9TKbHGztAF=r-io3gkX7gorUunS2UfstudCWuihrA=0g@mail.gmail.com >> >>>>> >> >>>>> I don't think that it's a good idea to mix 2 types of devices in one >> >>>>> subsystem (bus). If my understanding were correct, that breaks the >> >>>>> driver core convention. >> >>>>> >> >>>> >> >>>> All these are virtual devices .I am not sure i follow what you mean by 2 types of devices. >> >>>> memory_tiering is a subsystem that represents all the details w.r.t memory tiering. It shows >> >>>> details of memory tiers and can possibly contain details of different memory types . >> >>> >> >>> IMHO, memory_tier and memory_type are 2 kind of devices. They have >> >>> almost totally different attributes (sysfs file). So, we should create >> >>> 2 buses for them. Each has its own attribute group. "virtual" itself >> >>> isn't a subsystem. >> >> >> >> Considering both the details are related to memory tiering, wouldn't it be much simpler we consolidate >> >> them within the same subdirectory? I am still not clear why you are suggesting they need to be in different >> >> sysfs hierarchy. It doesn't break any driver core convention as you mentioned earlier. >> >> >> >> /sys/devices/virtual/memory_tiering/memory_tierN >> >> /sys/devices/virtual/memory_tiering/memory_typeN >> > >> > I think we should add >> > >> > /sys/devices/virtual/memory_tier/memory_tierN >> > /sys/devices/virtual/memory_type/memory_typeN >> > >> >> I am trying to find if there is a technical reason to do the same? >> >> > I don't think this is complex. Devices of same bus/subsystem should >> > have mostly same attributes. This is my understanding of driver core >> > convention. >> > >> >> I was not looking at this from code complexity point. Instead of having multiple directories >> with details w.r.t memory tiering, I was looking at consolidating the details >> within the directory /sys/devices/virtual/memory_tiering. (similar to all virtual devices >> are consolidated within /sys/devics/virtual/). >> >> -aneesh > > Here is an example of /sys/bus/nd/devices (I know it is not under > /sys/devices/virtual, but it can still serve as a reference): > > ls -1 /sys/bus/nd/devices > > namespace2.0 > namespace3.0 > ndbus0 > nmem0 > nmem1 > region0 > region1 > region2 > region3 > > So I think it is not unreasonable if we want to group memory tiering > related interfaces within a single top directory. Thanks for pointing this out. My original understanding of driver core isn't correct. But I still think it's better to separate instead of mixing memory_tier and memory_type. Per my understanding, memory_type shows information (abstract distance, latency, bandwidth, etc.) of memory types (and nodes), it can be useful even without memory tiers. That is, memory types describes the physical characteristics, while memory tier reflects the policy. Just my 2 cents. Best Regards, Huang, Ying