From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from internal-mail-relay1.corp.sgi.com (internal-mail-relay1.corp.sgi.com [198.149.32.52]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with ESMTP id k8C52v19015338 for ; Mon, 11 Sep 2006 22:02:57 -0700 Received: from spindle.corp.sgi.com (spindle.corp.sgi.com [198.29.75.13]) by internal-mail-relay1.corp.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id k8C2SE8s39342506 for ; Mon, 11 Sep 2006 19:28:14 -0700 (PDT) Received: from schroedinger.engr.sgi.com (schroedinger.engr.sgi.com [163.154.5.55]) by spindle.corp.sgi.com (SGI-8.12.5/8.12.9/generic_config-1.2) with ESMTP id k8C2SEnB56256190 for ; Mon, 11 Sep 2006 19:28:14 -0700 (PDT) Received: from christoph (helo=localhost) by schroedinger.engr.sgi.com with local-esmtp (Exim 3.36 #1 (Debian)) id 1GMy0T-000229-00 for ; Mon, 11 Sep 2006 19:28:13 -0700 Date: Mon, 11 Sep 2006 19:28:13 -0700 (PDT) From: Christoph Lameter Subject: A solution for more GFP_xx flags? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mm@kvack.org Return-Path: To: linux-mm@kvack.org List-ID: I wonder if we could pass a pointer to an allocation structure to the allocators instead of an unsigned long? Right now the problem is that we need _node allocators to specify nodes and the memory policies and cpusets are determined by the allocation context of a process. This makes the allocators difficult to handle. We could define a structure struct allocation_control { unsigned long flags; /* Traditional flags */ int node; struct cpuset_context *cpuset; struct mempol *mpol; }; We could define struct constants called GFP_KERNEL and GFP_ATOMIC. const struct allocation_control gfp_kernel { GFP_KERNEL, -1, NULL, NULL } And then do alloc_pages(n, gfp_kernel) ? This would also solve the problem of allocations that do not occur in a proper process context. F.e. slab allocations are on behalf of the slab allocator and not on behalf of a process. Thus the cpuset and the memory policies should not influence that allocation. In that case we could have a special allocation_control structure for that context. It would also get rid off all the xxx_node allocator variations. -- 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 From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <45061F16.202@yahoo.com.au> Date: Tue, 12 Sep 2006 12:44:38 +1000 From: Nick Piggin MIME-Version: 1.0 Subject: Re: A solution for more GFP_xx flags? References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org Return-Path: To: Christoph Lameter Cc: linux-mm@kvack.org List-ID: Christoph Lameter wrote: >I wonder if we could pass a pointer to an allocation structure >to the allocators instead of an unsigned long? > >Right now the problem is that we need _node allocators to specify nodes >and the memory policies and cpusets are determined by the allocation >context of a process. This makes the allocators difficult to handle. > >We could define a structure > >struct allocation_control { > unsigned long flags; /* Traditional flags */ > int node; > struct cpuset_context *cpuset; > struct mempol *mpol; >}; > >We could define struct constants called GFP_KERNEL and GFP_ATOMIC. >const struct allocation_control gfp_kernel { > GFP_KERNEL, -1, NULL, NULL >} > >And then do > >alloc_pages(n, gfp_kernel) > >? > >This would also solve the problem of allocations that do not occur in a >proper process context. F.e. slab allocations are on behalf of the slab >allocator and not on behalf of a process. Thus the cpuset and the memory >policies should not influence that allocation. In that case we could have >a special allocation_control structure for that context. > >It would also get rid off all the xxx_node allocator variations. > This seems like a decent approach to make a nice general interface. I guess existing APIs can be easily implemented by filling in the structure. If you took this approach I don't think there should be any objections. A minor point: would we prefer a struct argument to the allocator, or more function arguments? It is an API that we need to get right... --- Send instant messages to your online friends http://au.messenger.yahoo.com -- 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 From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Mon, 11 Sep 2006 20:01:20 -0700 (PDT) From: Christoph Lameter Subject: Re: A solution for more GFP_xx flags? In-Reply-To: <45061F16.202@yahoo.com.au> Message-ID: References: <45061F16.202@yahoo.com.au> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mm@kvack.org Return-Path: To: Nick Piggin Cc: linux-mm@kvack.org List-ID: On Tue, 12 Sep 2006, Nick Piggin wrote: > This seems like a decent approach to make a nice general interface. I guess > existing APIs can be easily implemented by filling in the structure. If you > took this approach I don't think there should be any objections. > > A minor point: would we prefer a struct argument to the allocator, or more > function arguments? It is an API that we need to get right... If you look at my allocator API (see the latest slab patchset), one could add all the allocator methods into the struct in order to objectivize the page alloator. The logical first step towards that would be to have a struct argument to allow detailed allocation control and to avoid this contextual memory policy / cpuset mess. -- 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 From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Tue, 12 Sep 2006 13:05:15 +1000 Message-ID: <87bqplaiok.wl%peterc@quokka.chubb.wattle.id.au> From: Peter Chubb In-Reply-To: References: <45061F16.202@yahoo.com.au> MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Subject: Re: A solution for more GFP_xx flags? Content-Type: text/plain; charset=US-ASCII Sender: owner-linux-mm@kvack.org Return-Path: To: Christoph Lameter Cc: Nick Piggin , linux-mm@kvack.org List-ID: >>>>> "Christoph" == Christoph Lameter writes: Christoph> On Tue, 12 Sep 2006, Nick Piggin wrote: >> This seems like a decent approach to make a nice general >> interface. I guess existing APIs can be easily implemented by >> filling in the structure. If you took this approach I don't think >> there should be any objections. >> >> A minor point: would we prefer a struct argument to the allocator, >> or more function arguments? It is an API that we need to get >> right... Christoph> If you look at my allocator API (see the latest slab Christoph> patchset), one could add all the allocator methods into the Christoph> struct in order to objectivize the page alloator. Dunno about you, but the thought of passing structs around on the stack gives me the heebie jeebies, especially if they're going to be more than a word or so big. Either pass by reference, or separate out the args, so it's explicit how much info's being copied around. -- Dr Peter Chubb http://www.gelato.unsw.edu.au peterc AT gelato.unsw.edu.au http://www.ertos.nicta.com.au ERTOS within National ICT Australia -- 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 From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Mon, 11 Sep 2006 20:07:10 -0700 (PDT) From: Christoph Lameter Subject: Re: A solution for more GFP_xx flags? In-Reply-To: <87bqplaiok.wl%peterc@quokka.chubb.wattle.id.au> Message-ID: References: <45061F16.202@yahoo.com.au> <87bqplaiok.wl%peterc@quokka.chubb.wattle.id.au> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mm@kvack.org Return-Path: To: Peter Chubb Cc: Nick Piggin , linux-mm@kvack.org List-ID: On Tue, 12 Sep 2006, Peter Chubb wrote: > Dunno about you, but the thought of passing structs around on the > stack gives me the heebie jeebies, especially if they're going to be > more than a word or so big. Right. > Either pass by reference, or separate out the args, so it's explicit > how much info's being copied around. Maybe I misunderstood Nick but I did not think he was proposing pushing structs on the stack. -- 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 From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Tue, 12 Sep 2006 13:11:44 +1000 Message-ID: <878xkpaidr.wl%peterc@quokka.chubb.wattle.id.au> From: Peter Chubb In-Reply-To: References: <45061F16.202@yahoo.com.au> <87bqplaiok.wl%peterc@quokka.chubb.wattle.id.au> MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Subject: Re: A solution for more GFP_xx flags? Content-Type: text/plain; charset=US-ASCII Sender: owner-linux-mm@kvack.org Return-Path: To: Christoph Lameter Cc: Peter Chubb , Nick Piggin , linux-mm@kvack.org List-ID: >>>>> "Christoph" == Christoph Lameter writes: Christoph> On Tue, 12 Sep 2006, Peter Chubb wrote: >> Dunno about you, but the thought of passing structs around on the >> stack gives me the heebie jeebies, especially if they're going to >> be more than a word or so big. Christoph> Right. >> Either pass by reference, or separate out the args, so it's >> explicit how much info's being copied around. Christoph> Maybe I misunderstood Nick but I did not think he was Christoph> proposing pushing structs on the stack. Maybe I misunderstood you: Christoph> We could define a structure Christoph> struct allocation_control { Christoph> unsigned long flags; /* Traditional flags */ Christoph> int node; Christoph> struct cpuset_context *cpuset; Christoph> struct mempol *mpol; Christoph> }; Christoph>We could define struct constants called GFP_KERNEL and GFP_ATOMIC. Christoph> const struct allocation_control gfp_kernel { Christoph> GFP_KERNEL, -1, NULL, NULL Christoph> } Christoph> And then do Christoph> alloc_pages(n, gfp_kernel) Did you mean alloc_pages(n, &gfp_kernel) ?? -- Dr Peter Chubb http://www.gelato.unsw.edu.au peterc AT gelato.unsw.edu.au http://www.ertos.nicta.com.au ERTOS within National ICT Australia -- 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 From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Mon, 11 Sep 2006 22:32:45 -0700 (PDT) From: Christoph Lameter Subject: Re: A solution for more GFP_xx flags? In-Reply-To: <878xkpaidr.wl%peterc@quokka.chubb.wattle.id.au> Message-ID: References: <45061F16.202@yahoo.com.au> <87bqplaiok.wl%peterc@quokka.chubb.wattle.id.au> <878xkpaidr.wl%peterc@quokka.chubb.wattle.id.au> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mm@kvack.org Return-Path: To: Peter Chubb Cc: Nick Piggin , linux-mm@kvack.org List-ID: On Tue, 12 Sep 2006, Peter Chubb wrote: > Did you mean alloc_pages(n, &gfp_kernel) ?? Yes. -- 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 From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from internal-mail-relay1.corp.sgi.com (internal-mail-relay1.corp.sgi.com [198.149.32.52]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with ESMTP id k8C8p89g006542 for ; Tue, 12 Sep 2006 01:51:08 -0700 Date: Mon, 11 Sep 2006 23:16:23 -0700 From: Paul Jackson Subject: Re: A solution for more GFP_xx flags? Message-Id: <20060911231623.a0d811ba.pj@sgi.com> In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org Return-Path: To: Christoph Lameter Cc: linux-mm@kvack.org List-ID: > struct allocation_control { > unsigned long flags; /* Traditional flags */ > int node; > struct cpuset_context *cpuset; I don't understand what purpose this cpuset pointer has. The main (heavily traveled) code paths beneath __alloc_pages() don't look at the tasks cpuset at all, and the less traveled code paths only look at the current tasks cpuset. I have no clue how the above cpuset pointer could (usefully) be anything other than just a copy of current->cpuset. Also, without serious reworking of the locking and likely some performance impact, I have no idea what use this cpuset pointer would be on the main memory allocation code paths. The cpuset imposed constraints on an allocation are represented by the mems_allowed nodemask and the flags PF_SPREAD_PAGE and PF_SPREAD_SLAB in the task struct. If the memory constraints imposed by a tasks cpuset change, then these constraints are transfered to the tasks mems_allowed and flags by the routine cpuset_update_task_memory_state(). Unlike mm/mempolicy.c NUMA mempolicies, one task -can- change the cpuset of another task. This forces us to have fancier (more expensive) locking on cpusets, and that means we have to keep cpusets off the hot memory allocation code paths and instead cache their constraints in the task struct. -- I won't rest till it's the best ... Programmer, Linux Scalability Paul Jackson 1.925.600.0401 -- 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