linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Anshuman Khandual <anshuman.khandual@arm.com>
To: Dan Williams <dan.j.williams@intel.com>,
	Dave Hansen <dave.hansen@intel.com>
Cc: Keith Busch <keith.busch@intel.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Linux ACPI <linux-acpi@vger.kernel.org>,
	Linux MM <linux-mm@kvack.org>,
	Greg KH <gregkh@linuxfoundation.org>,
	"Rafael J. Wysocki" <rafael@kernel.org>
Subject: Re: [PATCH 0/7] ACPI HMAT memory sysfs representation
Date: Mon, 26 Nov 2018 21:22:13 +0530	[thread overview]
Message-ID: <4b9e30ea-aa8e-cfd7-230b-1d5b0a8837f4@arm.com> (raw)
In-Reply-To: <CAPcyv4jnnnXi9Fqaf-d7AdnKrTMDCWr-e9tAx+G6nphrEPYm=w@mail.gmail.com>



On 11/24/2018 02:43 AM, Dan Williams wrote:
> On Fri, Nov 23, 2018 at 11:21 AM Dave Hansen <dave.hansen@intel.com> wrote:
>>
>> On 11/22/18 10:42 PM, Anshuman Khandual wrote:
>>> Are we willing to go in the direction for inclusion of a new system
>>> call, subset of it appears on sysfs etc ? My primary concern is not
>>> how the attribute information appears on the sysfs but lack of it's
>>> completeness.
>>
>> A new system call makes total sense to me.  I have the same concern
>> about the completeness of what's exposed in sysfs, I just don't see a
>> _route_ to completeness with sysfs itself.  Thus, the minimalist
>> approach as a first step.
> 
> Outside of platform-firmware-id to Linux-numa-node-id what other
> userspace API infrastructure does the kernel need to provide? It seems
> userspace enumeration of memory attributes is fully enabled once the
> firmware-to-Linux identification is established.

Which is true if the user space is required to probe the memory attribute
values for the platform-firmware-id from the platform and then request
required memory from corresponding Linux-numa-node-id via standard mm
interfaces like mbind(). But in this patch series we are not mapping
platform-firmware-id to Linux-numa-node-id. We are exporting properties
applicable to Linux nodes (Linux-numa-node-id).

Even if platform-firmware-id to Linux-numa-node-id is required it can
be done through a new file like the following. Applications can just
take the platform_id node and query platform about it's properties.

/sys/devices/system/node/nodeX/platform_id

This above interface would have been okay as its just an extension of
the existing node information on sysfs. But thats not the case with
this proposal.

  reply	other threads:[~2018-11-26 15:52 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-11-14 22:49 [PATCH 0/7] ACPI HMAT memory sysfs representation Keith Busch
2018-11-16  6:27 ` Anshuman Khandual
2018-11-16 15:51   ` Keith Busch
2018-11-19  1:52     ` Anshuman Khandual
2018-11-16 16:55   ` Dave Hansen
2018-11-19  5:44     ` Anshuman Khandual
2018-11-19 17:37       ` Dave Hansen
2018-11-22 11:52         ` Anshuman Khandual
2018-11-22 18:01           ` Dave Hansen
2018-11-23  6:42             ` Anshuman Khandual
2018-11-23 19:21               ` Dave Hansen
2018-11-23 21:13                 ` Dan Williams
2018-11-26 15:52                   ` Anshuman Khandual [this message]
2018-11-26 16:42                   ` Dave Hansen
2018-11-26 18:08                     ` Dan Williams
2018-11-27 10:15                       ` Anshuman Khandual
2018-11-27 16:56                         ` Dan Williams
2018-11-26 15:38                 ` Anshuman Khandual
2018-11-26 17:20                   ` Dave Hansen
2018-11-27  9:32                     ` Anshuman Khandual
2018-11-22 18:08           ` Dan Williams
2018-11-23  7:10             ` Anshuman Khandual
2018-11-23 17:15               ` Dan Williams
2018-11-27 14:05                 ` Anshuman Khandual

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4b9e30ea-aa8e-cfd7-230b-1d5b0a8837f4@arm.com \
    --to=anshuman.khandual@arm.com \
    --cc=dan.j.williams@intel.com \
    --cc=dave.hansen@intel.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=keith.busch@intel.com \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=rafael@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).