From: Jerome Glisse <jglisse@redhat.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Dan Williams <dan.j.williams@intel.com>,
Linux MM <linux-mm@kvack.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Ralph Campbell <rcampbell@nvidia.com>,
John Hubbard <jhubbard@nvidia.com>,
linux-fsdevel <linux-fsdevel@vger.kernel.org>
Subject: Re: [PATCH 09/10] mm/hmm: allow to mirror vma of a file on a DAX backed filesystem
Date: Wed, 6 Mar 2019 19:36:06 -0500 [thread overview]
Message-ID: <20190307003605.GB5528@redhat.com> (raw)
In-Reply-To: <20190306141820.d60e47d6e173d6ec171f52cf@linux-foundation.org>
On Wed, Mar 06, 2019 at 02:18:20PM -0800, Andrew Morton wrote:
> On Wed, 6 Mar 2019 10:49:04 -0500 Jerome Glisse <jglisse@redhat.com> wrote:
>
> > On Tue, Mar 05, 2019 at 02:16:35PM -0800, Andrew Morton wrote:
> > > On Wed, 30 Jan 2019 21:44:46 -0800 Dan Williams <dan.j.williams@intel.com> wrote:
> > >
> > > > >
> > > > > > Another way to help allay these worries is commit to no new exports
> > > > > > without in-tree users. In general, that should go without saying for
> > > > > > any core changes for new or future hardware.
> > > > >
> > > > > I always intend to have an upstream user the issue is that the device
> > > > > driver tree and the mm tree move a different pace and there is always
> > > > > a chicken and egg problem. I do not think Andrew wants to have to
> > > > > merge driver patches through its tree, nor Linus want to have to merge
> > > > > drivers and mm trees in specific order. So it is easier to introduce
> > > > > mm change in one release and driver change in the next. This is what
> > > > > i am doing with ODP. Adding things necessary in 5.1 and working with
> > > > > Mellanox to have the ODP HMM patch fully tested and ready to go in
> > > > > 5.2 (the patch is available today and Mellanox have begin testing it
> > > > > AFAIK). So this is the guideline i will be following. Post mm bits
> > > > > with driver patches, push to merge mm bits one release and have the
> > > > > driver bits in the next. I do hope this sound fine to everyone.
> > > >
> > > > The track record to date has not been "merge HMM patch in one release
> > > > and merge the driver updates the next". If that is the plan going
> > > > forward that's great, and I do appreciate that this set came with
> > > > driver changes, and maintain hope the existing exports don't go
> > > > user-less for too much longer.
> > >
> > > Decision time. Jerome, how are things looking for getting these driver
> > > changes merged in the next cycle?
> >
> > nouveau is merge already.
>
> Confused. Nouveau in mainline is dependent upon "mm/hmm: allow to
> mirror vma of a file on a DAX backed filesystem"? That can't be the
> case?
Not really, HMM mirror is about mirroring address space onto the device
so if mirroring does not work for file that are on a filesystem that use
DAX it fails in un-expected way from user point of view. But as nouveau
is just getting upstrean you can argue that no one previously depended
on that working for file backed page on DAX filesystem.
Now the ODP RDMA case is different, what is upstream today works on DAX
so if that patch is not upstream in 5.1 then i can not merge HMM ODP in
5.2 as it would regress and the ODP people would not take the risk of
regression ie ODP folks want the DAX support to be upstream first.
>
> > >
> > > Dan, what's your overall take on this series for a 5.1-rc1 merge?
> > >
> > > Jerome, what would be the risks in skipping just this [09/10] patch?
> >
> > As nouveau is a new user it does not regress anything but for RDMA
> > mlx5 (which i expect to merge new window) it would regress that
> > driver.
>
> Also confused. How can omitting "mm/hmm: allow to mirror vma of a file
> on a DAX backed filesystem" from 5.1-rc1 cause an mlx5 regression?
Not in 5.1 but i can not merge HMM ODP in 5.2 if that is not in 5.1.
I know this circular dependency between sub-system is painful but i
do not see any simpler way.
Cheers,
Jérôme
next prev parent reply other threads:[~2019-03-07 0:36 UTC|newest]
Thread overview: 98+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-01-29 16:54 [PATCH 00/10] HMM updates for 5.1 jglisse
2019-01-29 16:54 ` [PATCH 01/10] mm/hmm: use reference counting for HMM struct jglisse
2019-02-20 23:47 ` John Hubbard
2019-02-20 23:59 ` Jerome Glisse
2019-02-21 0:06 ` John Hubbard
2019-02-21 0:15 ` Jerome Glisse
2019-02-21 0:32 ` John Hubbard
2019-02-21 0:37 ` Jerome Glisse
2019-02-21 0:42 ` John Hubbard
2019-01-29 16:54 ` [PATCH 02/10] mm/hmm: do not erase snapshot when a range is invalidated jglisse
2019-02-20 23:58 ` John Hubbard
2019-01-29 16:54 ` [PATCH 03/10] mm/hmm: improve and rename hmm_vma_get_pfns() to hmm_range_snapshot() jglisse
2019-02-21 0:25 ` John Hubbard
2019-02-21 0:28 ` Jerome Glisse
2019-01-29 16:54 ` [PATCH 04/10] mm/hmm: improve and rename hmm_vma_fault() to hmm_range_fault() jglisse
2019-01-29 16:54 ` [PATCH 05/10] mm/hmm: improve driver API to work and wait over a range jglisse
2019-01-29 16:54 ` [PATCH 06/10] mm/hmm: add default fault flags to avoid the need to pre-fill pfns arrays jglisse
2019-01-29 16:54 ` [PATCH 07/10] mm/hmm: add an helper function that fault pages and map them to a device jglisse
2019-03-18 20:21 ` Dan Williams
2019-03-18 20:41 ` Jerome Glisse
2019-03-18 21:30 ` Dan Williams
2019-03-18 22:15 ` Jerome Glisse
2019-03-19 3:29 ` Dan Williams
2019-03-19 13:30 ` Jerome Glisse
2019-03-19 8:44 ` Ira Weiny
2019-03-19 17:10 ` Jerome Glisse
2019-03-19 14:10 ` Ira Weiny
2019-01-29 16:54 ` [PATCH 08/10] mm/hmm: support hugetlbfs (snap shoting, faulting and DMA mapping) jglisse
2019-01-29 16:54 ` [PATCH 09/10] mm/hmm: allow to mirror vma of a file on a DAX backed filesystem jglisse
2019-01-29 18:41 ` Dan Williams
2019-01-29 19:31 ` Jerome Glisse
2019-01-29 20:51 ` Dan Williams
2019-01-29 21:21 ` Jerome Glisse
2019-01-30 2:32 ` Dan Williams
2019-01-30 3:03 ` Jerome Glisse
2019-01-30 17:25 ` Dan Williams
2019-01-30 18:36 ` Jerome Glisse
2019-01-31 3:28 ` Dan Williams
2019-01-31 4:16 ` Jerome Glisse
2019-01-31 5:44 ` Dan Williams
2019-03-05 22:16 ` Andrew Morton
2019-03-06 4:20 ` Dan Williams
2019-03-06 15:51 ` Jerome Glisse
2019-03-06 15:57 ` Dan Williams
2019-03-06 16:03 ` Jerome Glisse
2019-03-06 16:06 ` Dan Williams
2019-03-07 17:46 ` Andrew Morton
2019-03-07 18:56 ` Jerome Glisse
2019-03-12 3:13 ` Dan Williams
2019-03-12 15:25 ` Jerome Glisse
2019-03-12 16:06 ` Dan Williams
2019-03-12 19:06 ` Jerome Glisse
2019-03-12 19:30 ` Dan Williams
2019-03-12 20:34 ` Dave Chinner
2019-03-13 1:06 ` Dan Williams
2019-03-12 21:52 ` Andrew Morton
2019-03-13 0:10 ` Jerome Glisse
2019-03-13 0:46 ` Dan Williams
2019-03-13 1:00 ` Jerome Glisse
2019-03-13 16:06 ` Andrew Morton
2019-03-13 18:39 ` Jerome Glisse
2019-03-06 15:49 ` Jerome Glisse
2019-03-06 22:18 ` Andrew Morton
2019-03-07 0:36 ` Jerome Glisse [this message]
2019-01-29 16:54 ` [PATCH 10/10] mm/hmm: add helpers for driver to safely take the mmap_sem jglisse
2019-02-20 21:59 ` John Hubbard
2019-02-20 22:19 ` Jerome Glisse
2019-02-20 22:40 ` John Hubbard
2019-02-20 23:09 ` Jerome Glisse
2019-02-20 23:17 ` [PATCH 00/10] HMM updates for 5.1 John Hubbard
2019-02-20 23:36 ` Jerome Glisse
2019-02-22 23:31 ` Ralph Campbell
2019-03-13 1:27 ` Jerome Glisse
2019-03-13 16:10 ` Andrew Morton
2019-03-13 18:01 ` Jason Gunthorpe
2019-03-13 18:33 ` Jerome Glisse
2019-03-18 17:00 ` Kuehling, Felix
2019-03-18 17:04 ` Jerome Glisse
2019-03-18 18:30 ` Dan Williams
2019-03-18 18:54 ` Jerome Glisse
2019-03-18 19:18 ` Dan Williams
2019-03-18 19:28 ` Jerome Glisse
2019-03-18 19:36 ` Dan Williams
2019-03-19 16:40 ` Andrew Morton
2019-03-19 16:58 ` Jerome Glisse
2019-03-19 17:12 ` Andrew Morton
2019-03-19 17:18 ` Jerome Glisse
2019-03-19 17:33 ` Dan Williams
2019-03-19 17:45 ` Jerome Glisse
2019-03-19 18:42 ` Dan Williams
2019-03-19 19:05 ` Jerome Glisse
2019-03-19 19:13 ` Dan Williams
2019-03-19 14:18 ` Ira Weiny
2019-03-19 22:24 ` Jerome Glisse
2019-03-19 19:18 ` Jerome Glisse
2019-03-19 20:25 ` Jerome Glisse
2019-03-19 21:51 ` Stephen Rothwell
2019-03-19 18:51 ` Deucher, Alexander
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=20190307003605.GB5528@redhat.com \
--to=jglisse@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=dan.j.williams@intel.com \
--cc=jhubbard@nvidia.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.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;
as well as URLs for NNTP newsgroup(s).