Re: [PATCH] rmap 18 i_mmap_nonlinear

[Hugh Dickins]

On Wed, 28 Apr 2004, William Lee Irwin III wrote:
> On Wed, Apr 28, 2004 at 07:11:18PM -0400, Rik van Riel wrote:
> > ... do we still need both i_mmap and i_mmap_shared?
> > Is there a place left where we're using both trees in
> > a different way, or are we just walking both trees
> > anyway in all places where they're referenced ?

Good point from Rik.  I very nearly combined them in this patchset
(and was trying to avoid adding i_mmap_nonlinear on top, but Rajesh
gently persuaded me that would be a little foolish, the nonlinear
processing too different).

I'm sure i_mmap and i_mmap_shared can and should be combined (with
addition of a count of shared writable mappings, for those places
which need to know if there were any at all); but in the end decided
to leave that for later, consult the architectures affected first.

Another change to contemplate: we should be able to add page_mapped
checks to cut down on the flushing, this stuff was written before
there was any such count.  But it's not straightforward: maybe some
of the flush_dcache_page calls come just before the rmap is added,
yet would be relying on it to be counted in?

> I believe the flush_dcache_page() implementations touching
> ->i_mmap_shared care about this distinction.

That's right, arm and parisc do handle them differently: currently
arm ignores i_mmap (and I think rmk was wondering a few months ago
whether that's actually correct, given that MAP_SHARED mappings
which can never become writable go in there - and that surprise is
itself a very good reason for combining them), and parisc... ah,
what it does in Linus' tree at present is about the same for both,
but there are some changes on the way.

The differences are not going to be enough to deserve two separate
prio_tree_roots in every struct address_space, we can check vm_flags
for any differences if necessary.

Something else I should have commented on, in that patch comment or
the next: although we now have the separate i_mmap_nonlinear list,
no attempt to search it for nonlinear pages in flush_dcache_page.

It looks like parisc has no sys_remap_file_pages syscall anyway,
and arm only flushes current active_mm, so should be okay so long
as people don't mix linear and nonlinear maps of same pages (hmm,
and don't map same page twice in a nonlinear: more likely) in same
mm: anyway, I think any problems there have to be a "Don't do that",
searching page tables in flush_dcache_page would be too too painful.

Hugh

-
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/