To: Hubertus Franke/Watson/IBM@IBMUS cc: Kanoj Sarcar , Paul McKenney/Beaverton/IBM@IBMUS, andi@suse.de, andrea@suse.de, aono@ed2.com1.fc.nec.co.jp, beckman@turbolabs.com, bjorn_helgaas@hp.com, Jerry.Harrow@Compaq.com, jwright@engr.sgi.com, kanoj@engr.sgi.com, kumon@flab.fujitsu.co.jp, norton@mclinux.com, suganuma@hpc.bs1.fc.nec.co.jp, sunil.saxena@intel.com, tbutler@hi.com, woodman@missioncriticallinux.com, mikek@sequent.com, Kenneth Rozendal/Austin/IBM@IBMUS, kumon@flab.fujitsu.co.jp Date: 03/30/01 02:39 PM From: kumon@flab.fujitsu.co.jp Subject: Re: NUMA-on-Linux roadmap, version 2 I definitely agree with you Hubertus. Hubertus Franke writes: > I already pointed out to Paul that some of the API, such as cpu-binding > and memory binding applies to large scale SMP as well. All of optimization we've done on NUMA is also usefull for SMP. A large cache can be treated as a local memory. At least, in a past year I posted SMP code improvements to LKML based on our NUMA machine experience. > In that light, it might be useful to restate our goal to > "SMP and NUMA-API" and start layering it. In generally, NUMA has longer memory access time and therefore NUMA is much sensitive to "SMP optimization" But, at some of the time, NUMA optimization differs from SMP. Because, a process on NUMA has a origin of memory, but SMP has a symmetrical memory view. -- Kouichi Kumon Computer Systems Laboratory, Fujitsu Labs. kumon@flab.fujitsu.co.jp