From: Logan Gunthorpe <logang@deltatee.com>
To: Jerome Glisse <jglisse@redhat.com>
Cc: Dan Williams <dan.j.williams@intel.com>,
Andi Kleen <ak@linux.intel.com>, Linux MM <linux-mm@kvack.org>,
Andrew Morton <akpm@linux-foundation.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
"Rafael J. Wysocki" <rafael@kernel.org>,
Dave Hansen <dave.hansen@intel.com>,
Haggai Eran <haggaie@mellanox.com>,
balbirs@au1.ibm.com,
"Aneesh Kumar K.V" <aneesh.kumar@linux.ibm.com>,
Benjamin Herrenschmidt <benh@kernel.crashing.org>,
"Kuehling, Felix" <felix.kuehling@amd.com>,
Philip.Yang@amd.com, "Koenig,
Christian" <christian.koenig@amd.com>,
"Blinzer, Paul" <Paul.Blinzer@amd.com>,
John Hubbard <jhubbard@nvidia.com>,
rcampbell@nvidia.com
Subject: Re: [RFC PATCH 02/14] mm/hms: heterogenenous memory system (HMS) documentation
Date: Tue, 4 Dec 2018 14:19:09 -0700 [thread overview]
Message-ID: <e4d8bf6b-5b2c-58a5-577b-66d02f2342c1@deltatee.com> (raw)
In-Reply-To: <20181204205902.GM2937@redhat.com>
On 2018-12-04 1:59 p.m., Jerome Glisse wrote:
> How to expose harmful memory to userspace then ? How can i expose
> non cache coherent memory because yes they are application out there
> that use that today and would like to be able to migrate to and from
> that memory dynamicly during lifetime of the application as the data
> set progress through the application processing pipeline.
I'm not arguing against the purpose or use cases. I'm being critical of
the API choices.
> Note that i do not expose things like physical address or even splits
> memory in a node into individual device, in fact in expose less
> information that the existing NUMA (no zone, phys index, ...). As i do
> not think those have any value to userspace. What matter to userspace
> is where is this memory is in my topology so i can look at all the
> initiators node that are close by. Or the reverse, i have a set of
> initiators what is the set of closest targets to all those initiators.
No, what matters to applications is getting memory that will work for
the initiators/resources they need it to work for. The specific topology
might be of interest to administrators but it is not what applications
need. And it should be relatively easy to flesh out the existing sysfs
device tree to provide the topology information administrators need.
> I am talking about the inevitable fact that at some point some system
> firmware will miss-represent their platform. System firmware writer
> usualy copy and paste thing with little regards to what have change
> from one platform to the new. So their will be inevitable workaround
> and i would rather see those piling up inside a userspace library than
> inside the kernel.
It's *absolutely* the kernel's responsibility to patch issues caused by
broken firmware. We have quirks all over the place for this. That's
never something userspace should be responsible for. Really, this is the
raison d'etre of the kernel: to provide userspace with a uniform
execution environment -- if every application had to deal with broken
firmware it would be a nightmare.
Logan
next prev parent reply other threads:[~2018-12-04 21:19 UTC|newest]
Thread overview: 95+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-12-03 23:34 [RFC PATCH 00/14] Heterogeneous Memory System (HMS) and hbind() jglisse
2018-12-03 23:34 ` [RFC PATCH 01/14] mm/hms: heterogeneous memory system (sysfs infrastructure) jglisse
2018-12-03 23:34 ` [RFC PATCH 02/14] mm/hms: heterogenenous memory system (HMS) documentation jglisse
2018-12-04 17:06 ` Andi Kleen
2018-12-04 18:24 ` Jerome Glisse
2018-12-04 18:31 ` Dan Williams
2018-12-04 18:57 ` Jerome Glisse
2018-12-04 19:11 ` Logan Gunthorpe
2018-12-04 19:22 ` Jerome Glisse
2018-12-04 19:41 ` Logan Gunthorpe
2018-12-04 20:13 ` Jerome Glisse
2018-12-04 20:30 ` Logan Gunthorpe
2018-12-04 20:59 ` Jerome Glisse
2018-12-04 21:19 ` Logan Gunthorpe [this message]
2018-12-04 21:51 ` Jerome Glisse
2018-12-04 22:16 ` Logan Gunthorpe
2018-12-04 23:56 ` Jerome Glisse
2018-12-05 1:15 ` Logan Gunthorpe
2018-12-05 2:31 ` Jerome Glisse
2018-12-05 17:41 ` Logan Gunthorpe
2018-12-05 18:07 ` Jerome Glisse
2018-12-05 18:20 ` Logan Gunthorpe
2018-12-05 18:33 ` Jerome Glisse
2018-12-05 18:48 ` Logan Gunthorpe
2018-12-05 18:55 ` Jerome Glisse
2018-12-05 19:10 ` Logan Gunthorpe
2018-12-05 22:58 ` Jerome Glisse
2018-12-05 23:09 ` Logan Gunthorpe
2018-12-05 23:20 ` Jerome Glisse
2018-12-05 23:23 ` Logan Gunthorpe
2018-12-05 23:27 ` Jerome Glisse
2018-12-06 0:08 ` Dan Williams
2018-12-05 2:34 ` Dan Williams
2018-12-05 2:37 ` Jerome Glisse
2018-12-05 17:25 ` Logan Gunthorpe
2018-12-05 18:01 ` Jerome Glisse
2018-12-04 20:14 ` Andi Kleen
2018-12-04 20:47 ` Logan Gunthorpe
2018-12-04 21:15 ` Jerome Glisse
2018-12-05 0:54 ` Kuehling, Felix
2018-12-04 19:19 ` Dan Williams
2018-12-04 19:32 ` Jerome Glisse
2018-12-04 20:12 ` Andi Kleen
2018-12-04 20:41 ` Jerome Glisse
2018-12-05 4:36 ` Aneesh Kumar K.V
2018-12-05 4:41 ` Jerome Glisse
2018-12-05 10:52 ` Mike Rapoport
2018-12-03 23:34 ` [RFC PATCH 03/14] mm/hms: add target memory to heterogeneous memory system infrastructure jglisse
2018-12-03 23:34 ` [RFC PATCH 04/14] mm/hms: add initiator " jglisse
2018-12-03 23:35 ` [RFC PATCH 05/14] mm/hms: add link " jglisse
2018-12-03 23:35 ` [RFC PATCH 06/14] mm/hms: add bridge " jglisse
2018-12-03 23:35 ` [RFC PATCH 07/14] mm/hms: register main memory with heterogenenous memory system jglisse
2018-12-03 23:35 ` [RFC PATCH 08/14] mm/hms: register main CPUs " jglisse
2018-12-03 23:35 ` [RFC PATCH 09/14] mm/hms: hbind() for heterogeneous memory system (aka mbind() for HMS) jglisse
2018-12-03 23:35 ` [RFC PATCH 10/14] mm/hbind: add heterogeneous memory policy tracking infrastructure jglisse
2018-12-03 23:35 ` [RFC PATCH 11/14] mm/hbind: add bind command to heterogeneous memory policy jglisse
2018-12-03 23:35 ` [RFC PATCH 12/14] mm/hbind: add migrate command to hbind() ioctl jglisse
2018-12-03 23:35 ` [RFC PATCH 13/14] drm/nouveau: register GPU under heterogeneous memory system jglisse
2018-12-03 23:35 ` [RFC PATCH 14/14] test/hms: tests for " jglisse
2018-12-04 7:44 ` [RFC PATCH 00/14] Heterogeneous Memory System (HMS) and hbind() Aneesh Kumar K.V
2018-12-04 14:44 ` Jerome Glisse
2018-12-04 18:02 ` Dave Hansen
2018-12-04 18:49 ` Jerome Glisse
2018-12-04 18:54 ` Dave Hansen
2018-12-04 19:11 ` Jerome Glisse
2018-12-04 21:37 ` Dave Hansen
2018-12-04 21:57 ` Jerome Glisse
2018-12-04 23:58 ` Dave Hansen
2018-12-05 0:29 ` Jerome Glisse
2018-12-05 1:22 ` Kuehling, Felix
2018-12-05 11:27 ` Aneesh Kumar K.V
2018-12-05 16:09 ` Jerome Glisse
2018-12-04 23:54 ` Dave Hansen
2018-12-05 0:15 ` Jerome Glisse
2018-12-05 1:06 ` Dave Hansen
2018-12-05 2:13 ` Jerome Glisse
2018-12-05 17:27 ` Dave Hansen
2018-12-05 17:53 ` Jerome Glisse
2018-12-06 18:25 ` Dave Hansen
2018-12-06 19:20 ` Jerome Glisse
2018-12-06 19:31 ` Dave Hansen
2018-12-06 20:11 ` Logan Gunthorpe
2018-12-06 22:04 ` Dave Hansen
2018-12-06 22:39 ` Jerome Glisse
2018-12-06 23:09 ` Dave Hansen
2018-12-06 23:28 ` Logan Gunthorpe
2018-12-06 23:34 ` Dave Hansen
2018-12-06 23:38 ` Dave Hansen
2018-12-06 23:48 ` Logan Gunthorpe
2018-12-07 0:20 ` Jerome Glisse
2018-12-07 15:06 ` Jonathan Cameron
2018-12-07 19:37 ` Jerome Glisse
2018-12-07 0:15 ` Jerome Glisse
2018-12-06 20:27 ` Jerome Glisse
2018-12-06 21:46 ` Jerome Glisse
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=e4d8bf6b-5b2c-58a5-577b-66d02f2342c1@deltatee.com \
--to=logang@deltatee.com \
--cc=Paul.Blinzer@amd.com \
--cc=Philip.Yang@amd.com \
--cc=ak@linux.intel.com \
--cc=akpm@linux-foundation.org \
--cc=aneesh.kumar@linux.ibm.com \
--cc=balbirs@au1.ibm.com \
--cc=benh@kernel.crashing.org \
--cc=christian.koenig@amd.com \
--cc=dan.j.williams@intel.com \
--cc=dave.hansen@intel.com \
--cc=felix.kuehling@amd.com \
--cc=haggaie@mellanox.com \
--cc=jglisse@redhat.com \
--cc=jhubbard@nvidia.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=rafael@kernel.org \
--cc=rcampbell@nvidia.com \
/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