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 D6682ECAAA1 for ; Fri, 2 Sep 2022 06:40:40 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 34FF7800BF; Fri, 2 Sep 2022 02:40:40 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 2D9278008D; Fri, 2 Sep 2022 02:40:40 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 17B47800BF; Fri, 2 Sep 2022 02:40:40 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 0718D8008D for ; Fri, 2 Sep 2022 02:40:40 -0400 (EDT) Received: from smtpin27.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id E7086A10AC for ; Fri, 2 Sep 2022 06:40:39 +0000 (UTC) X-FDA: 79866196998.27.7326526 Received: from mga05.intel.com (mga05.intel.com [192.55.52.43]) by imf09.hostedemail.com (Postfix) with ESMTP id 997A5140068 for ; Fri, 2 Sep 2022 06:40:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1662100838; x=1693636838; h=from:to:cc:subject:references:date:in-reply-to: message-id:mime-version; bh=sE6sa0vwx0FKfcHDMJ+oRYmOnHHQlFAFE5YS9SVeHls=; b=N8JGzgbqZS9cEmw0dLSYHZjV+jU+a+ZkXfNouzGDcviI+2ltxvM2+wOB IDH77FIIPSOihGsBY8v2b8zzLNpQEFAIBEJXjGyHgCvV8fZrowa94VVVz mqUdVS5yKPY5f/KXIwbhCfHRY5vtH0DtmSpdIDt3rkTbfKQvFVIXHvcDn l0w2zA8K6PgCO3cTvXx99SoP3Qj7nx5Hotp16Ii7ONIOqWg37c9ztu3NV u26l6ukBEW9Z4r5m7UuiiM6Dm1+yU79K0Y5oqLA6lCtWGgMFdSeNU1Agk QKvr+A34uuZ7U8TrLk7D30thq4Fuh78fcTKQNC8C5u6XfFA051QuJ8bvF Q==; X-IronPort-AV: E=McAfee;i="6500,9779,10457"; a="382207401" X-IronPort-AV: E=Sophos;i="5.93,283,1654585200"; d="scan'208";a="382207401" Received: from fmsmga005.fm.intel.com ([10.253.24.32]) by fmsmga105.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 01 Sep 2022 23:40:36 -0700 X-IronPort-AV: E=Sophos;i="5.93,283,1654585200"; d="scan'208";a="941173805" Received: from yhuang6-desk2.sh.intel.com (HELO yhuang6-desk2.ccr.corp.intel.com) ([10.238.208.55]) by fmsmga005-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 01 Sep 2022 23:40:32 -0700 From: "Huang, Ying" To: Aneesh Kumar K V Cc: Wei Xu , Johannes Weiner , 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 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> Date: Fri, 02 Sep 2022 14:40:30 +0800 In-Reply-To: <2b4ddc45-74ae-27df-d973-6724f61f4e18@linux.ibm.com> (Aneesh Kumar K. V.'s message of "Fri, 2 Sep 2022 12:01:43 +0530") Message-ID: <877d2mz3c1.fsf@yhuang6-desk2.ccr.corp.intel.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=ascii ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1662100839; 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=2FMRH9r7x7YnNLkp3WY7QttcC0kotfqyImh8wxCguVA=; b=bmmS5rM01BvPC4DfFcGabms9oogPGm8SGJvpvPKpV5LQrZAzB9EHaTest+3wcmBHVH6XwI nWSf0Ve5JEXknxr5L5G7OJOx9JbsHNaBt0O4Iz1KFiF0T6u4vSBVTAE6paG9VYYiDHnHWL 1asn0xeSdsRNS9TwYQR7LHd9BdY/ZAk= ARC-Authentication-Results: i=1; imf09.hostedemail.com; dkim=none ("invalid DKIM record") header.d=intel.com header.s=Intel header.b=N8JGzgbq; spf=pass (imf09.hostedemail.com: domain of ying.huang@intel.com designates 192.55.52.43 as permitted sender) smtp.mailfrom=ying.huang@intel.com; dmarc=pass (policy=none) header.from=intel.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1662100839; a=rsa-sha256; cv=none; b=1NIuHG1vrBF/N8vZ2dclv1H/pkXw4VSn9Zyf2dmQEefZbCFLQ09WQR3P1OdRvozyHpK6Cw FUWrFtbw4xervtU2qS4dnAFS8gfRdXy89INzvkKgcvrsdm6pzfOPUBAyXaSi81F57eb1Ca KbNpY0ceLznCNNpuOgtxL1biKrQddZQ= X-Stat-Signature: 56xxjzcikazkamkrqdqbxsy1dx311ukx X-Rspamd-Queue-Id: 997A5140068 Authentication-Results: imf09.hostedemail.com; dkim=none ("invalid DKIM record") header.d=intel.com header.s=Intel header.b=N8JGzgbq; spf=pass (imf09.hostedemail.com: domain of ying.huang@intel.com designates 192.55.52.43 as permitted sender) smtp.mailfrom=ying.huang@intel.com; dmarc=pass (policy=none) header.from=intel.com X-Rspamd-Server: rspam05 X-Rspam-User: X-HE-Tag: 1662100837-936372 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: 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 don't think this is complex. Devices of same bus/subsystem should have mostly same attributes. This is my understanding of driver core convention. Best Regards, Huang, Ying