Re: [PATCH/RFC 0/11] Shared Policy Overview

[Christoph Lameter <clameter@sgi.com>]

On Fri, 29 Jun 2007, Lee Schermerhorn wrote:

> As I've said before, we can DO that, if you think it's needed.  E.g., we
> can require write access to a file in order to install a shared policy.
> Probably a good idea anyway.  Processes that have write access to a
> shared, mmap()ed file BETTER be cooperating.

They currently do not do that.

> Mapped shared file policy is off by default.  Documentation explain the
> implications of turning on for applications that share mapped files
> between cpusets.  We need to do this anyway, for shmem.  How many bug
> reports have you seen from this scenario for shmem segments which behave
> exactly the same?

I think about 7 or so shmem related that were escalated to our team? We 
put in the policy specification for shmem on the kernel command line for a 
reason. You boot the kernel with the policy you want shmem to have and 
tell all other people that may attempt to set a policy on shmem to stay 
the *** away from it.

> Do the bug reports specify whether the mapping is for private or shared
> mappings?  VMA policies ARE applied to page cache pages of private
> mappings if the process COWs the page.   For shared mappings, if we used

Yes but not if the proccess simply reads the page and that is the simple 
case that could be fixed by passing the policy to page_cache_alloc() 
without weird shared sematics on volatile memory objects.

--
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>