[lkml]   [2004]   [Apr]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [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
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 14:02    [W:0.043 / U:0.096 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site