Messages in this thread | | | Date | Thu, 29 Apr 2004 07:10:59 +0100 (BST) | From | Hugh Dickins <> | Subject | Re: [PATCH] rmap 18 i_mmap_nonlinear |
| |
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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |