From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from lists.gentoo.org ([140.105.134.102] helo=robin.gentoo.org) by nuthatch.gentoo.org with esmtp (Exim 4.43) id 1DxjS6-0006Uc-8a for garchives@archives.gentoo.org; Wed, 27 Jul 2005 10:47:54 +0000 Received: from robin.gentoo.org (localhost [127.0.0.1]) by robin.gentoo.org (8.13.4/8.13.4) with SMTP id j6RAkBkc007762; Wed, 27 Jul 2005 10:46:11 GMT Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.193]) by robin.gentoo.org (8.13.4/8.13.4) with ESMTP id j6RAkAh4006791 for ; Wed, 27 Jul 2005 10:46:11 GMT Received: by wproxy.gmail.com with SMTP id 71so142518wri for ; Wed, 27 Jul 2005 03:46:28 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=TxfTDtck+DqbrsxNARQp2FF15oldy6kaEKHR9sa049wtK9hiLZwUYVqMb4AzJveluDLxzJI0ft87Yat42Xgs24rSluFRI0/goOlxmNXsZQOsZa8z3BFYD0FP+zaomMpOcJSw1jDP1Ue7FYC8Ndh1epiFZobAK+E7VfFym6zqb9M= Received: by 10.54.67.8 with SMTP id p8mr274665wra; Wed, 27 Jul 2005 03:46:28 -0700 (PDT) Received: by 10.54.123.5 with HTTP; Wed, 27 Jul 2005 03:46:28 -0700 (PDT) Message-ID: <81469e8e0507270346445f4363@mail.gmail.com> Date: Wed, 27 Jul 2005 05:46:28 -0500 From: Drew Kirkpatrick To: gentoo-amd64@lists.gentoo.org Subject: Re: [gentoo-amd64] Re: amd64 and kernel configuration In-Reply-To: Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-amd64@gentoo.org Reply-to: gentoo-amd64@lists.gentoo.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <20050727062947.73020.qmail@mail.mng.mn> <25f58b7910e09fd5453bb3ec534330d1@xsmail.com> <20050727075012.79549.qmail@mail.mng.mn> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by robin.gentoo.org id j6RAkAh4006791 X-Archives-Salt: 4dc94c68-99cd-438b-a2e2-84a0744b38d9 X-Archives-Hash: b57cac5423fa3839c9329abb97b7e371 Just to point out, amd was calling the opterons and such more of a SUMO configuration (Sufficiently Uniform Memory Organization, not joking here), instead of NUMA. Whereas technically, it clearly is a NUMA system, the differences in latency when accessing memory from a bank attached to another processors memory controller is very small. Small enough to be largely ignored, and treated like uniform memory access latencies in a SMP system. Sorta in between SMP unified style memory access and NUMA. This holds for up to 3 hypertranport link hops, or up to 8 chips/sockets. You add hypertransport switches to scale over 8 chips/sockets, it'll most likely be a different story... What I've always wondered is, the NUMA code in the linux kernel, is this for handling traditional NUMA, like in a large computer system (big iron) where NUMA memory access latencies will vary greatly, or is it simply for optimizing the memory usage across the memory banks. Keeping data in the memory of the processor using it, etc, etc. Of course none of this matters for single chip/socket amd systems, as dual cores as well as single cores share a memory controller. Hmm, maybe I should drink some coffee and shutup until I'm awake... On 7/27/05, Duncan <1i5t5.duncan@cox.net> wrote: > Dulmandakh Sukhbaatar posted <20050727075012.79549.qmail@mail.mng.mn>, > excerpted below, on Wed, 27 Jul 2005 15:50:12 +0800: > > > Thanks. How can I enable hypertransport in kernel or somewhere? Anyone > > knows about NUMA? I read about it, and it seems technology for > > multiprocessor systems. Thus I have single CPU, I don't need it. Right? > > NUMA is indeed for multi-processor systems. NUMA is Non-Uniform Memory > Architecture. With AMD CPUs that have the memory controller on the same > chip as the CPU, that means that each CPU can control it's own memory. If > you run NUMA mode in this case (and if your BIOS is set up accordingly), > the kernel will try to keep the memory for each task in the memory handled > by, local to, that CPU. If either the kernel or BIOS is set to unified > memory, or if you only have memory sticks in the slots for one of the > CPUs, then you won't get NUMA mode and the kernel won't care what memory > addresses the memory for each process lives at. > > AFAIK, hypertransport is automatically handled by your choice of chipset. > If the chipset you configure has it, it will be enabled, if not, it won't. > I was therefore a bit puzzled when you mentioned hypertransport > specifically in the previous post, since I don't believe there's a > specific kernel option for it. (It's possible, however, that there is and > I've just forgotten about it, since it's been awhile since I reviewed > the settings for the entire kernel -- I just run make oldconfig and deal > with any new options in each newer kernel, and additionally do any > specific tweaking I might want to try.) > > -- > Duncan - List replies preferred. No HTML msgs. > "Every nonfree program has a lord, a master -- > and if you use the program, he is your master." Richard Stallman in > http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html > > > -- > gentoo-amd64@gentoo.org mailing list > > -- gentoo-amd64@gentoo.org mailing list