Messages in this thread | | | Date | Wed, 28 Apr 2004 23:32:56 -0700 | From | William Lee Irwin III <> | Subject | Re: [PATCH] rmap 18 i_mmap_nonlinear |
| |
On Wed, 28 Apr 2004, William Lee Irwin III wrote: >> I believe the flush_dcache_page() implementations touching >> ->i_mmap_shared care about this distinction.
On Thu, Apr 29, 2004 at 07:10:59AM +0100, Hugh Dickins wrote: > 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.
It seemed these two actually wanted a precise recovery of virtual addresses and the like for flush_dcache_page() like they would have had with pte_chains, but never got around to using it.
On Thu, Apr 29, 2004 at 07:10:59AM +0100, Hugh Dickins wrote: > 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.
Maybe it's worth #ifdef'ing out core remap_file_pages() support for those arches if all it can do is harm to them wrt. cache coherency issues. ARM probably wouldn't mind conserving the code it otherwise wouldn't use.
-- wli - 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/
| |