Re: [PATCH] rmap 18 i_mmap_nonlinear

[William Lee Irwin III]

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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/