From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Fri, 25 May 2007 14:43:52 -0700 (PDT) From: Christoph Lameter Subject: Re: [PATCH/RFC 0/8] Mapped File Policy Overview In-Reply-To: <1180127552.21879.15.camel@localhost> Message-ID: References: <20070524172821.13933.80093.sendpatchset@localhost> <200705242241.35373.ak@suse.de> <1180040744.5327.110.camel@localhost> <1180104952.5730.28.camel@localhost> <1180109165.5730.32.camel@localhost> <1180114648.5730.64.camel@localhost> <1180127552.21879.15.camel@localhost> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mm@kvack.org Return-Path: To: Lee Schermerhorn Cc: Andi Kleen , linux-mm@kvack.org, akpm@linux-foundation.org, nish.aravamudan@gmail.com List-ID: On Fri, 25 May 2007, Lee Schermerhorn wrote: > ??? Why? Different processes could set different policies on the file > in the file system. The last one [before the file was mapped?] would > rule. Then the policy would be set on a file and not by processes. So there is one way of controlling the memory policy. > Seems like a lot of extra effort that could be applied to other tasks, > but you've worn me down. I'll debug the numa_maps hang with hugetlb > shmem segments with shared policy in the current code base, and reorder > the patch set to handle correct display of shmem policy from all tasks > first. Next week or so. It may be worthwhile to split off the huge tlb pieces and cc those interested in huge pages. Maybe they can be treated like shmem? -- 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