From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Tue, 26 Jun 2007 20:25:11 -0700 (PDT) From: Christoph Lameter Subject: Re: [PATCH/RFC 0/11] Shared Policy Overview In-Reply-To: <200706270042.27365.ak@suse.de> Message-ID: References: <20070625195224.21210.89898.sendpatchset@localhost> <200706270042.27365.ak@suse.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mm@kvack.org Return-Path: To: Andi Kleen Cc: Lee Schermerhorn , linux-mm@kvack.org, akpm@linux-foundation.org, nacc@us.ibm.com List-ID: On Wed, 27 Jun 2007, Andi Kleen wrote: > > You are sure that this works? Just by looking at the description: It > > cannot work. Any allocator use of a memory policy must use rcu locks > > otherwise the memory policy can vanish from under us while allocating a > > page. This means you need to add this to alloc_pages_current > > and alloc_pages_node. Possible all of __alloc_pages must be handled > > under RCU. This is a significant increase of RCU use. > > I've been actually looking at using RCUs for the shared policies > too to plug the recent reference count issue. I don't think it's a problem > because the RCU use can be limited to when policies are actually > used. Besides rcu_read_lock() is a nop on non preemptible kernels > anyways and users of preemptible kernels will probably not notice > it among all the other overhead they have anyways. If a system policy is set then it will be used all of the time. Could be a signficant increase in RCU use. > > If we can make this work then RCU should be used for all policies so that > > we can get rid of the requirement that policies can only be modified from > > the task context that created it. > > Huh? RCU doesn't give you locking against multiple writers. Just existence > guarantees. And you can have those already by just holding the reference > count. If you want to replace one policy by another then RCU ensures that the old policy can still be used for the remainder of the rcu period. If RCU is not used then the updating of a policy is not possible since there is currently no locking and there may be concurrent uses of the policy or the zonelist generated by a policy. One thread may acquire the pointer to a policy while another changes the policy. If the old policy is immediately freed then the first thread may access invalid data. -- 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