LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Jerome Glisse <jglisse@redhat.com>
To: Dan Williams <dan.j.williams@intel.com>
Cc: Dave Airlie <airlied@gmail.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Logan Gunthorpe <logang@deltatee.com>,
	Christoph Hellwig <hch@lst.de>, Michal Hocko <mhocko@suse.com>,
	Linux MM <linux-mm@kvack.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 0/5] mm: rework hmm to use devm_memremap_pages
Date: Thu, 7 Jun 2018 10:16:41 -0400	[thread overview]
Message-ID: <20180607141640.GA4518@redhat.com> (raw)
In-Reply-To: <CAPcyv4gsS4xDXahZdOggURBHS2y-oJ5tPG9vXPDdY2p6jPufxA@mail.gmail.com>

On Tue, Jun 05, 2018 at 06:33:04PM -0700, Dan Williams wrote:
> On Tue, Jun 5, 2018 at 5:08 PM, Jerome Glisse <jglisse@redhat.com> wrote:
> > On Tue, Jun 05, 2018 at 04:06:12PM -0700, Dan Williams wrote:
> [..]
> >> I want the EXPORT_SYMBOL_GPL on devm_memremap_pages() primarily for
> >> development purposes. Any new users of devm_memremap_pages() should be
> >> aware that they are subscribing to the whims of the core-VM, i.e. the
> >> ongoing evolution of 'struct page', and encourage those drivers to be
> >> upstream to improve the implementation, and consolidate use cases. I'm
> >> not qualified to comment on your "nor will it change anyone's legal
> >> position.", but I'm saying it's in the Linux kernel's best interest
> >> that new users of this interface assume they need to be GPL.
> >
> > Note that HMM isolate the device driver from struct page as long as
> > the driver only use HMM helpers to get to the information it needs.
> > I intend to be pedantic about that with any driver using HMM. I want
> > HMM to be an impedance layer that provide stable and simple API to
> > device driver while preserving freedom of change to mm.
> >
> 
> I would not classify redefining put_page() and recompiling the
> entirety of the kernel to turn on HMM as "isolating the driver from
> 'struct page'". HMM is instead isolating these out of drivers from
> ever needing to go upstream.

Well i guess it is better to leave it there as i don't think we can
agree on that. I spelled out the API contract HMM is providing and it
can be implemented in other ways. The fact that it uses ZONE_DEVICE is
an implementation details to driver using HMM. In essence driver is
not subscribing in anyway to the whims of the core-VM.

> 
> Unless the nouveau patches are using the entirety of what is already
> upstream for HMM, we should look to pare HMM back.

Nouveau patches use everything in HMM, including ZONE_DEVICE private,
excluding ZONE_DEVICE public for now. The ZONE_DEVICE public is only
meaningful on PowerPC platform for now and it requires Volta GPU.

Volta GPU is in the process of being enabled in the open source driver
and it will take few months before we reach the point where we will look
into adding ZONE_DEVICE public support for PowerPC.


> There is plenty of precedent of building a large capability
> out-of-tree and piecemeal merging it later, so I do not buy the
> "chicken-egg" argument. The change in the export is to make sure we
> don't repeat this backward "merge first, ask questions later" mistake
> in the future as devm_memremap_pages() is continuing to find new users
> like peer-to-peer DMA support and Linux is better off if that
> development is upstream. From a purely technical standpoint
> devm_memremap_pages() is EXPORT_SYMBOL_GPL because it hacks around
> several implementation details in the core kernel to achieve its goal,
> and it leaks new assumptions all over the kernel. It is strictly not a
> self contained interface.

HMM is self contain interface but i doubt i can convince you of that.

Cheers,
Jérôme

  parent reply	other threads:[~2018-06-07 14:16 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-05-21 22:35 Dan Williams
2018-05-21 22:35 ` [PATCH 1/5] mm, devm_memremap_pages: mark devm_memremap_pages() EXPORT_SYMBOL_GPL Dan Williams
2018-05-22  6:29   ` Christoph Hellwig
2018-05-21 22:35 ` [PATCH 2/5] mm, devm_memremap_pages: handle errors allocating final devres action Dan Williams
2018-05-21 23:10   ` Andrew Morton
2018-05-22  0:07     ` Dan Williams
2018-05-22 16:42       ` Logan Gunthorpe
2018-05-22 16:56         ` Dan Williams
2018-05-22 17:03           ` Logan Gunthorpe
2018-05-22 17:25             ` Dan Williams
2018-05-22 17:36               ` Logan Gunthorpe
2018-05-22  6:30   ` Christoph Hellwig
2018-05-21 22:35 ` [PATCH 3/5] mm, hmm: use devm semantics for hmm_devmem_{add, remove} Dan Williams
2018-05-22  6:30   ` Christoph Hellwig
2018-05-21 22:35 ` [PATCH 4/5] mm, hmm: replace hmm_devmem_pages_create() with devm_memremap_pages() Dan Williams
2018-05-22  6:31   ` Christoph Hellwig
2018-05-22 17:13   ` Logan Gunthorpe
2018-05-22 21:38     ` Dan Williams
2018-05-21 22:35 ` [PATCH 5/5] mm, hmm: mark hmm_devmem_{add, add_resource} EXPORT_SYMBOL_GPL Dan Williams
2018-05-22  6:32   ` Christoph Hellwig
2018-05-22 21:31     ` Andrew Morton
2018-06-05 18:24       ` Jerome Glisse
2018-05-24  0:10 ` [PATCH 0/5] mm: rework hmm to use devm_memremap_pages Jerome Glisse
2018-05-24  3:18   ` Dan Williams
2018-05-24  6:35     ` Christoph Hellwig
2018-05-29 22:22     ` Dave Airlie
2018-05-29 22:31       ` Dan Williams
2018-05-29 23:00         ` Dave Airlie
2018-05-29 23:33           ` Dan Williams
2018-06-05 18:48             ` Jerome Glisse
2018-06-05 22:19               ` Dave Airlie
2018-06-05 23:06                 ` Dan Williams
2018-06-06  0:08                   ` Jerome Glisse
2018-06-06  1:33                     ` Dan Williams
2018-06-06  7:14                       ` Christoph Hellwig
2018-06-07 14:16                       ` Jerome Glisse [this message]
2018-06-07 18:39                         ` Dan Williams

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=20180607141640.GA4518@redhat.com \
    --to=jglisse@redhat.com \
    --cc=airlied@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=dan.j.williams@intel.com \
    --cc=hch@lst.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=logang@deltatee.com \
    --cc=mhocko@suse.com \
    --subject='Re: [PATCH 0/5] mm: rework hmm to use devm_memremap_pages' \
    /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

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).