Re: [PATCH/RFC]

Re: [PATCH/RFC]

[Christoph Lameter]

On Thu, 20 Apr 2006, Lee Schermerhorn wrote:

> Basic "problem":  currently [2.6.17-rc1], file mmap()ed SHARED
> do not follow policy applied to the mapped regions.  Instead, 
> shared file backed pages are allocated using the allocating
> tasks' task policy.  This is inconsistent with the way that anon
> and shmem pages are handled.

You mean pages generated while writing to an MMAP_PRIVATE area follow 
policy (these are anonymous pages). Not that the pags from the file follow 
policy right?

> One reason for this is that down where pages are allocated for
> file backed pages, the faulting (mm, vma, address) are not 
> available to compute the policy.  However, we do have the inode
> [via the address space] and file index/offset available.  If the
> applicable policy could be determined from just this info, the
> vma and address would not be required.

Processes may set individual policies per file. If you do this then there 
will be overhead generated through a need for these shared policy 
structures. It seems then that this shared policy has the same semantics 
as shmem? Exists after processes have terminated?

> Cursory testing with memtoy for shm segments, shared and privately
> mapped files; single task and 2 tasks mmap()ing same file.  When
> the file is mmap()ed shared, either task's policy changes are seen
> by both tasks.  When one maps shared and the other private, the
> private mapper's policies apply only to its mapping.

Again we are talking about private pages in the sense of the anonymous 
pages generated by writing to a private mapping?

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>