From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Thu, 20 Apr 2006 16:51:12 -0700 (PDT) From: Christoph Lameter Subject: Re: [PATCH/RFC] In-Reply-To: <1145565435.5214.31.camel@localhost.localdomain> Message-ID: References: <1145565435.5214.31.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Benjamin LaHaise Return-Path: To: Lee Schermerhorn Cc: linux-mm , Andi Kleen , Eric Whitney List-ID: 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: email@kvack.org