From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757201AbXJ2UCa (ORCPT ); Mon, 29 Oct 2007 16:02:30 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1753379AbXJ2UCU (ORCPT ); Mon, 29 Oct 2007 16:02:20 -0400 Received: from netops-testserver-4-out.sgi.com ([192.48.171.29]:44068 "EHLO relay.sgi.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1752453AbXJ2UCT (ORCPT ); Mon, 29 Oct 2007 16:02:19 -0400 Date: Mon, 29 Oct 2007 13:02:17 -0700 From: Paul Jackson To: Lee Schermerhorn Cc: rientjes@google.com, clameter@sgi.com, akpm@linux-foundation.org, ak@suse.de, linux-kernel@vger.kernel.org Subject: Re: [patch 2/2] cpusets: add interleave_over_allowed option Message-Id: <20071029130217.6dd46df0.pj@sgi.com> In-Reply-To: <1193676854.5035.121.camel@localhost> References: <20071025185506.8c373aa8.pj@sgi.com> <1193412644.5032.13.camel@localhost> <20071026120037.7b95a136.pj@sgi.com> <1193433239.5032.95.camel@localhost> <1193434278.5032.106.camel@localhost> <20071026180713.aeedfac2.pj@sgi.com> <20071026194144.6042316a.pj@sgi.com> <20071027161955.e9d4d2db.pj@sgi.com> <1193676854.5035.121.camel@localhost> Organization: SGI X-Mailer: Sylpheed version 2.2.4 (GTK+ 2.8.3; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Lee wrote: > In libnuma in numactl-1.0.2 that I recently grabbed off Andi's site, > numa_available() indeed issues this call. But, I don't see any internal > calls to numa_available() [comments says all other calls undefined when > numa_available() returns an error] nor any other calls to > get_mempolicy() with all null/0 args. So, you'd be depending on the > application to call numa_available(). Aha - good point. It happened to be the numactl command line utility that I tested with that issued the get_mempolicy(0,0,0,0,0) call. Yup - this proposed hack, to have the kernel revert to the original memory policy nodemask numbering if it sees such a getmempolicy call is now officially dead meat. Thanks. > However, you could define an > additional MPOL_F_* flag to get_mempolicy() that is issued in library > init code to enable new behavior--again, based on some indication that > new behavior is desired or not. Yes - I am intending to define such MPOL_F_* flags, to set and get which behavior applies to the current task. -- I won't rest till it's the best ... Programmer, Linux Scalability Paul Jackson 1.925.600.0401