linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@linux-foundation.org>
To: Jerome Glisse <j.glisse@gmail.com>
Cc: Joerg Roedel <joro@8bytes.org>,
	Andrea Arcangeli <aarcange@redhat.com>,
	Rik van Riel <riel@redhat.com>,
	jroedel@suse.de, Peter Zijlstra <a.p.zijlstra@chello.nl>,
	John.Bridgman@amd.com, Jesse Barnes <jbarnes@virtuousgeek.org>,
	Hugh Dickins <hughd@google.com>,
	linux-kernel@vger.kernel.org, ben.sander@amd.com,
	linux-mm@kvack.org, Jerome Glisse <jglisse@redhat.com>,
	Jay.Cornwall@amd.com, Mel Gorman <mgorman@suse.de>,
	David Woodhouse <dwmw2@infradead.org>,
	Johannes Weiner <jweiner@redhat.com>,
	iommu@lists.linux-foundation.org
Subject: Re: [PATCH 0/3 v3] mmu_notifier: Allow to manage CPU external TLBs
Date: Fri, 12 Sep 2014 12:27:37 -0700	[thread overview]
Message-ID: <20140912122737.53a7947e5378fa501092887b@linux-foundation.org> (raw)
In-Reply-To: <20140912192100.GB5196@gmail.com>

On Fri, 12 Sep 2014 15:21:01 -0400 Jerome Glisse <j.glisse@gmail.com> wrote:

> > > I think this sumup all motivation behind this patchset and also behind
> > > my other patchset. As usual i am happy to discuss alternative way to do
> > > things but i think that the path of least disruption from current code
> > > is the one implemented by those patchset.
> > 
> > "least disruption" is nice, but "good implementation" is better.  In
> > other words I'd prefer the more complex implementation if the end
> > result is better.  Depending on the magnitudes of "complex" and
> > "better" :) Two years from now (which isn't very long), I don't think
> > we'll regret having chosen the better implementation.
> > 
> > Does this patchset make compromises to achieve low disruption?
> 
> Well right now i think we are lacking proper userspace support with which
> this code and the global new usecase can be stress tested allowing to gather
> profiling information.
> 
> I think as a first step we should take this least disruptive path and if
> it proove to perform badly then we should work toward possibly more complex
> design. Note that only complex design i can think of involve an overhaul of
> how process memory management is done and probably linking cpu page table
> update with the scheduler to try to hide cost of those update by scheduling
> other thread meanwhile.

OK.  Often I'd resist merging a patchset when we're not sure it will be
sufficient.  But there are practical advantages to doing so and the
present patchset is quite simple.  So if we decide to remove it later
on the impact will be small.  If the patchset made userspace-visible
changes then things would be different!

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

  reply	other threads:[~2014-09-12 19:27 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-09-09 15:43 Joerg Roedel
2014-09-09 15:43 ` [PATCH 1/3] mmu_notifier: Add mmu_notifier_invalidate_range() Joerg Roedel
2014-09-09 15:43 ` [PATCH 2/3] mmu_notifier: Call mmu_notifier_invalidate_range() from VMM Joerg Roedel
2014-09-09 15:43 ` [PATCH 3/3] mmu_notifier: Add the call-back for mmu_notifier_invalidate_range() Joerg Roedel
2014-09-10 22:01 ` [PATCH 0/3 v3] mmu_notifier: Allow to manage CPU external TLBs Andrew Morton
2014-09-11  0:02   ` Jerome Glisse
2014-09-12 18:39     ` Jerome Glisse
2014-09-12 19:10     ` Andrew Morton
2014-09-12 19:21       ` Jerome Glisse
2014-09-12 19:27         ` Andrew Morton [this message]
2014-09-12 18:47   ` Joerg Roedel
2014-09-12 19:19     ` Andrew Morton
2014-09-12 19:28       ` 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=20140912122737.53a7947e5378fa501092887b@linux-foundation.org \
    --to=akpm@linux-foundation.org \
    --cc=Jay.Cornwall@amd.com \
    --cc=John.Bridgman@amd.com \
    --cc=a.p.zijlstra@chello.nl \
    --cc=aarcange@redhat.com \
    --cc=ben.sander@amd.com \
    --cc=dwmw2@infradead.org \
    --cc=hughd@google.com \
    --cc=iommu@lists.linux-foundation.org \
    --cc=j.glisse@gmail.com \
    --cc=jbarnes@virtuousgeek.org \
    --cc=jglisse@redhat.com \
    --cc=joro@8bytes.org \
    --cc=jroedel@suse.de \
    --cc=jweiner@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mgorman@suse.de \
    --cc=riel@redhat.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