Re: [PATCH 0/3 v3] mmu_notifier: Allow to manage CPU external TLBs

[Andrew Morton]

On Fri, 12 Sep 2014 15:21:01 -0400 Jerome Glisse <j.glisse@xxxxxxxxx> 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 from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/