From owner-freebsd-current@FreeBSD.ORG Fri Sep 19 05:45:31 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D89A0106566B for ; Fri, 19 Sep 2008 05:45:31 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outW.internet-mail-service.net (outw.internet-mail-service.net [216.240.47.246]) by mx1.freebsd.org (Postfix) with ESMTP id C36E28FC2A for ; Fri, 19 Sep 2008 05:45:31 +0000 (UTC) (envelope-from julian@elischer.org) Received: from idiom.com (mx0.idiom.com [216.240.32.160]) by out.internet-mail-service.net (Postfix) with ESMTP id EFAD62385 for ; Thu, 18 Sep 2008 22:45:31 -0700 (PDT) Received: from julian-mac.elischer.org (localhost [127.0.0.1]) by idiom.com (Postfix) with ESMTP id 6197C2D600D for ; Thu, 18 Sep 2008 22:45:31 -0700 (PDT) Message-ID: <48D33C7A.7010007@elischer.org> Date: Thu, 18 Sep 2008 22:45:30 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.16 (Macintosh/20080707) MIME-Version: 1.0 To: FreeBSD Current Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: amd opteron NUMA support X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Sep 2008 05:45:31 -0000 Is anyone looking at trying to add specific support for the hyper-transport based numa AMD systems? It would be interesting to know what sort of things Sun did for Solaris for their old x-bus systems which had similar characteristics. with each processor having memory associated with it, and a penalty for accessing memory associated with other CPUS, several things come to mind, including: Obviously, doing a lot of work to stop threads from migrating around. Page replacement of pages that are 'far away' with closer ones over time. CPU or die specific memory allocators. Multiple copies of read-only segments (so that each cpu has it's own copy of the /bin/sh text segment for example). Servicing interrupts on CPUs most closely associated with the IO channels. Now I know SOME work has been done on some of this but it would be good to know if anyone if focusing on this. Julian (who just did a quick course on opteron and has come away quite stunned)