linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Michal Hocko <mhocko@kernel.org>
To: "Tetsuo Handa" <penguin-kernel@I-love.SAKURA.ne.jp>,
	"Jérôme Glisse" <jglisse@redhat.com>
Cc: "Andrew Morton" <akpm@linux-foundation.org>,
	LKML <linux-kernel@vger.kernel.org>,
	linux-mm@kvack.org, "David (ChunMing) Zhou" <David1.Zhou@amd.com>,
	"Paolo Bonzini" <pbonzini@redhat.com>,
	"Radim Krčmář" <rkrcmar@redhat.com>,
	"Alex Deucher" <alexander.deucher@amd.com>,
	"David Airlie" <airlied@linux.ie>,
	"Jani Nikula" <jani.nikula@linux.intel.com>,
	"Joonas Lahtinen" <joonas.lahtinen@linux.intel.com>,
	"Rodrigo Vivi" <rodrigo.vivi@intel.com>,
	"Doug Ledford" <dledford@redhat.com>,
	"Jason Gunthorpe" <jgg@ziepe.ca>,
	"Mike Marciniszyn" <mike.marciniszyn@intel.com>,
	"Dennis Dalessandro" <dennis.dalessandro@intel.com>,
	"Sudeep Dutt" <sudeep.dutt@intel.com>,
	"Ashutosh Dixit" <ashutosh.dixit@intel.com>,
	"Dimitri Sivanich" <sivanich@sgi.com>,
	"Boris Ostrovsky" <boris.ostrovsky@oracle.com>,
	"Juergen Gross" <jgross@suse.com>,
	"Andrea Arcangeli" <aarcange@redhat.com>,
	"Felix Kuehling" <felix.kuehling@amd.com>,
	kvm@vger.kernel.org, amd-gfx@lists.freedesktop.org,
	dri-devel@lists.freedesktop.org, intel-gfx@lists.freedesktop.org,
	linux-rdma@vger.kernel.org, xen-devel@lists.xenproject.org,
	"Christian König" <christian.koenig@amd.com>,
	"David Rientjes" <rientjes@google.com>,
	"Leon Romanovsky" <leonro@mellanox.com>
Subject: Re: [PATCH] mm, oom: distinguish blockable mode for mmu notifiers
Date: Fri, 24 Aug 2018 13:36:29 +0200	[thread overview]
Message-ID: <20180824113629.GI29735@dhcp22.suse.cz> (raw)
In-Reply-To: <8cbfb09f-0c5a-8d43-1f5e-f3ff7612e289@I-love.SAKURA.ne.jp>

On Fri 24-08-18 19:54:19, Tetsuo Handa wrote:
[...]
> > --- a/mm/hmm.c
> > +++ b/mm/hmm.c
> > @@ -177,16 +177,19 @@ static void hmm_release(struct mmu_notifier *mn, struct mm_struct *mm)
> >         up_write(&hmm->mirrors_sem);
> >  }
> > 
> > -static void hmm_invalidate_range_start(struct mmu_notifier *mn,
> > +static int hmm_invalidate_range_start(struct mmu_notifier *mn,
> >                                        struct mm_struct *mm,
> >                                        unsigned long start,
> > -                                      unsigned long end)
> > +                                      unsigned long end,
> > +                                      bool blockable)
> >  {
> >         struct hmm *hmm = mm->hmm;
> > 
> >         VM_BUG_ON(!hmm);
> > 
> >         atomic_inc(&hmm->sequence);
> > +
> > +       return 0;
> >  }
> > 
> >  static void hmm_invalidate_range_end(struct mmu_notifier *mn,
> 
> This assumes that hmm_invalidate_range_end() does not have memory
> allocation dependency. But hmm_invalidate_range() from
> hmm_invalidate_range_end() involves
> 
>         down_read(&hmm->mirrors_sem);
>         list_for_each_entry(mirror, &hmm->mirrors, list)
>                 mirror->ops->sync_cpu_device_pagetables(mirror, action,
>                                                         start, end);
>         up_read(&hmm->mirrors_sem);
> 
> sequence. What is surprising is that there is no in-tree user who assigns
> sync_cpu_device_pagetables field.

Yes HMM doesn't have any in tree user yet.

>   $ grep -Fr sync_cpu_device_pagetables *
>   Documentation/vm/hmm.rst:     /* sync_cpu_device_pagetables() - synchronize page tables
>   include/linux/hmm.h: * will get callbacks through sync_cpu_device_pagetables() operation (see
>   include/linux/hmm.h:    /* sync_cpu_device_pagetables() - synchronize page tables
>   include/linux/hmm.h:    void (*sync_cpu_device_pagetables)(struct hmm_mirror *mirror,
>   include/linux/hmm.h: * hmm_mirror_ops.sync_cpu_device_pagetables() callback, so that CPU page
>   mm/hmm.c:               mirror->ops->sync_cpu_device_pagetables(mirror, action,
> 
> That is, this API seems to be currently used by only out-of-tree users. Since
> we can't check that nobody has memory allocation dependency, I think that
> hmm_invalidate_range_start() should return -EAGAIN if blockable == false for now.

The code expects that the invalidate_range_end doesn't block if
invalidate_range_start hasn't blocked. That is the reason why the end
callback doesn't have blockable parameter. If this doesn't hold then the
whole scheme is just fragile because those two calls should pair.

-- 
Michal Hocko
SUSE Labs

  parent reply	other threads:[~2018-08-24 11:36 UTC|newest]

Thread overview: 45+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-07-16 11:50 [PATCH] mm, oom: distinguish blockable mode for mmu notifiers Michal Hocko
2018-07-16 23:12 ` Andrew Morton
2018-07-17  4:03   ` Leon Romanovsky
2018-07-17  8:12   ` Michal Hocko
2018-07-20 23:01     ` Andrew Morton
2018-07-23  8:43       ` Michal Hocko
2018-07-19  9:12 ` Michal Hocko
2018-07-21  0:09 ` Andrew Morton
2018-07-23  7:03   ` Michal Hocko
2018-07-23  7:11     ` Michal Hocko
2018-07-23  8:11       ` Michal Hocko
2018-07-24 14:17   ` Michal Hocko
2018-07-24 19:53     ` Andrew Morton
2018-07-25  6:17       ` Michal Hocko
2018-07-24 21:07     ` David Rientjes
2018-07-25  6:13       ` Michal Hocko
2018-08-24 10:54 ` Tetsuo Handa
2018-08-24 11:32   ` Michal Hocko
2018-08-24 11:43     ` Christian König
2018-08-24 11:52       ` Michal Hocko
2018-08-24 11:57         ` Christian König
2018-08-24 12:03           ` Michal Hocko
2018-08-24 12:18             ` Christian König
2018-08-24 12:33               ` Michal Hocko
2018-08-24 12:52                 ` Christian König
2018-08-24 13:01                   ` Michal Hocko
2018-08-24 13:10                     ` Christian König
2018-08-24 13:24                       ` Michal Hocko
2018-08-24 13:28                         ` Christian König
2018-08-24 13:40                           ` Michal Hocko
2018-08-24 13:44                             ` Christian König
2018-08-24 13:52                               ` Michal Hocko
2018-08-26  8:40                                 ` Tetsuo Handa
2018-08-27  7:41                                   ` Christian König
2018-09-06 22:46                                     ` Tetsuo Handa
2018-08-24 15:08                 ` Jerome Glisse
2018-08-24 11:36   ` Michal Hocko [this message]
2018-08-24 13:02     ` Tetsuo Handa
2018-08-24 13:32       ` Michal Hocko
2018-08-24 14:52         ` Tetsuo Handa
2018-08-24 15:12           ` Jerome Glisse
2018-08-24 16:40             ` Michal Hocko
2018-08-24 17:33               ` Jerome Glisse
2018-08-24 16:38           ` Michal Hocko
2018-08-24 14:40   ` 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=20180824113629.GI29735@dhcp22.suse.cz \
    --to=mhocko@kernel.org \
    --cc=David1.Zhou@amd.com \
    --cc=aarcange@redhat.com \
    --cc=airlied@linux.ie \
    --cc=akpm@linux-foundation.org \
    --cc=alexander.deucher@amd.com \
    --cc=amd-gfx@lists.freedesktop.org \
    --cc=ashutosh.dixit@intel.com \
    --cc=boris.ostrovsky@oracle.com \
    --cc=christian.koenig@amd.com \
    --cc=dennis.dalessandro@intel.com \
    --cc=dledford@redhat.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=felix.kuehling@amd.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=jani.nikula@linux.intel.com \
    --cc=jgg@ziepe.ca \
    --cc=jglisse@redhat.com \
    --cc=jgross@suse.com \
    --cc=joonas.lahtinen@linux.intel.com \
    --cc=kvm@vger.kernel.org \
    --cc=leonro@mellanox.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linux-rdma@vger.kernel.org \
    --cc=mike.marciniszyn@intel.com \
    --cc=pbonzini@redhat.com \
    --cc=penguin-kernel@I-love.SAKURA.ne.jp \
    --cc=rientjes@google.com \
    --cc=rkrcmar@redhat.com \
    --cc=rodrigo.vivi@intel.com \
    --cc=sivanich@sgi.com \
    --cc=sudeep.dutt@intel.com \
    --cc=xen-devel@lists.xenproject.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).