From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Wed, 9 Oct 2002 22:59:41 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Wed, 9 Oct 2002 22:59:41 -0400 Received: from packet.digeo.com ([12.110.80.53]:9631 "EHLO packet.digeo.com") by vger.kernel.org with ESMTP id ; Wed, 9 Oct 2002 22:59:39 -0400 Message-ID: <3DA4EE6C.6B4184CC@digeo.com> Date: Wed, 09 Oct 2002 20:05:16 -0700 From: Andrew Morton X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.5.41 i686) X-Accept-Language: en MIME-Version: 1.0 To: colpatch@us.ibm.com CC: linux-kernel , linux-mm@kvack.org, LSE , Martin Bligh , Michael Hohnbaum Subject: Re: [rfc][patch] Memory Binding API v0.3 2.5.41 References: <3DA4D3E4.6080401@us.ibm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 10 Oct 2002 03:05:17.0333 (UTC) FILETIME=[DC546450:01C27009] Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Matthew Dobson wrote: > > Greetings & Salutations, > Here's a wonderful patch that I know you're all dying for... Memory > Binding! Seems reasonable to me. Could you tell us a bit about the operator's view of this? I assume that a typical usage scenario would be to bind a process to a bunch of CPUs and to then bind that process to a bunch of memblks as well? If so, then how does the operator know how to identify those memblks? To perform the (cpu list) <-> (memblk list) mapping? Also, what advantage does this provide over the current node-local allocation policy? I'd have thought that once you'd bound a process to a CPU (or to a node's CPUs) that as long as the zone fallback list was right, that process would be getting local memory pretty much all the time anyway? Last but not least: you got some benchmark numbers for this? Thanks. From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from digeo-nav01.digeo.com (digeo-nav01.digeo.com [192.168.1.233]) by packet.digeo.com (8.9.3+Sun/8.9.3) with SMTP id UAA16477 for ; Wed, 9 Oct 2002 20:05:17 -0700 (PDT) Message-ID: <3DA4EE6C.6B4184CC@digeo.com> Date: Wed, 09 Oct 2002 20:05:16 -0700 From: Andrew Morton MIME-Version: 1.0 Subject: Re: [rfc][patch] Memory Binding API v0.3 2.5.41 References: <3DA4D3E4.6080401@us.ibm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org Return-Path: To: colpatch@us.ibm.com Cc: linux-kernel , linux-mm@kvack.org, LSE , Martin Bligh , Michael Hohnbaum List-ID: Matthew Dobson wrote: > > Greetings & Salutations, > Here's a wonderful patch that I know you're all dying for... Memory > Binding! Seems reasonable to me. Could you tell us a bit about the operator's view of this? I assume that a typical usage scenario would be to bind a process to a bunch of CPUs and to then bind that process to a bunch of memblks as well? If so, then how does the operator know how to identify those memblks? To perform the (cpu list) <-> (memblk list) mapping? Also, what advantage does this provide over the current node-local allocation policy? I'd have thought that once you'd bound a process to a CPU (or to a node's CPUs) that as long as the zone fallback list was right, that process would be getting local memory pretty much all the time anyway? Last but not least: you got some benchmark numbers for this? Thanks. -- 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/