[lkml]   [2008]   [Jan]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [patch 2/6] mmu_notifier: Callbacks to invalidate address ranges
On Wed, 30 Jan 2008, Jack Steiner wrote:

> > Seems that we cannot rely on the invalidate_ranges for correctness at all?
> > We need to have invalidate_page() always. invalidate_range() is only an
> > optimization.
> >
> I don't understand your point "an optimization". How would invalidate_range
> as currently defined be correctly used?

We are changing definitions. The original patch by Andrea calls
invalidate_page for each pte that is cleared. So strictly you would not
need an invalidate_range.

> It _looks_ like it would work only if xpmem/gru/etc takes a refcnt on
> the page & drops it when invalidate_range is called. That may work (not sure)
> for xpmem but not for the GRU.

The refcount is not necessary if we adopt Andrea's approach of a callback
on the clearing of each pte. At that point the page is still guaranteed to
exist. If we do the range_invalidate later (as in V3) then the page may
have been released (see sys_remap_file_pages() f.e.) before we zap the GRU
ptes. So there will be a time when the GRU may write to a page that has
been freed and used for another purpose.

Taking a refcount on the page defers the free until the range_invalidate

I would prefer a solution that does not require taking refcounts (pins)
for establishing an external pte and for release (like what the GRU does).

If we could effectively determine that there are no external ptes in a
range then the invalidate_page() call may return immediately. Maybe it is
then effective to do these gazillions of invalidate_page() calls when a
process terminates or an remap is performed.

 \ /
  Last update: 2008-01-30 21:59    [W:0.110 / U:5.092 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site