To: kumon@flab.fujitsu.co.jp cc: andi@suse.de, andrea@suse.de, aono@ed2.com1.fc.nec.co.jp, beckman@turbolabs.com, bjorn_helgaas@hp.com, Hubertus Franke/Watson/IBM@IBMUS, Jerry.Harrow@Compaq.com, jwright@engr.sgi.com, kanoj@engr.sgi.com, Kanoj Sarcar , Kenneth Rozendal/Austin/IBM@IBMUS, kumon@flab.fujitsu.co.jp, mikek@sequent.com, norton@mclinux.com, suganuma@hpc.bs1.fc.nec.co.jp, sunil.saxena@intel.com, tbutler@hi.com, woodman@missioncriticallinux.com Date: 03/30/01 11:31 PM From: Paul McKenney/Beaverton/IBM@IBMUS 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. Me, too. The NUMA-optimization and SMP-optimization roads go the same direction for quite a ways, but they do eventually diverge. However, a 16-way NUMA will need all the SMP optimizations required by a 16-way SMP, plus some additional NUMA optimizations. Thanx, Paul