From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id 0AE121381F3 for ; Sat, 15 Dec 2012 03:18:15 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id EF1B721C006; Sat, 15 Dec 2012 03:17:59 +0000 (UTC) Received: from mail-bk0-f53.google.com (mail-bk0-f53.google.com [209.85.214.53]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 80CB3E0478 for ; Sat, 15 Dec 2012 03:16:32 +0000 (UTC) Received: by mail-bk0-f53.google.com with SMTP id j5so2007956bkw.40 for ; Fri, 14 Dec 2012 19:16:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=/RQQDp+ZtccF55O/+mYeILp2yuKJE5pkcDYnSPuOhcY=; b=ebDd+5d74xV4ajSYdzSRQcscgwQjsK87DvkbZOrhb6gyn3m9u1Co87CzjCItoiMcBM oEpgOl4KNqFQvqHMSgs6iLTVps/VAt87M8rNVw9Pqr2Mkl9gnh4b6u6LAQGG+WPRrndi n08Se6x+JjuBrIIqfEaqkSoB5QGCuPoVer0aQXCJFHrX1690pQqayJdPTzZZPL9I9RmF NIQBRFvrr0BX11kLm7q2A0zdsr2/ROzl0eQ42Q2sv/RYQno0Uc+AHiwdQeG+ft+8HIe+ oINyiDMufqWMInrnhDvl/b43cNpMhoebVtz0B3+1Bs3R73K2GYBnL4Ouhf6QR5ac72Ox GCkw== Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user@lists.gentoo.org Reply-to: gentoo-user@lists.gentoo.org MIME-Version: 1.0 Received: by 10.204.5.69 with SMTP id 5mr3495473bku.26.1355541391006; Fri, 14 Dec 2012 19:16:31 -0800 (PST) Received: by 10.205.99.72 with HTTP; Fri, 14 Dec 2012 19:16:30 -0800 (PST) In-Reply-To: References: <20121213082346.7b6bae37@khamul.example.com> <50C98588.9080409@binarywings.net> Date: Fri, 14 Dec 2012 19:16:30 -0800 Message-ID: Subject: Re: [gentoo-user] Dual or Quad CPU complications? From: Grant To: Gentoo mailing list Content-Type: multipart/alternative; boundary=00151758a6e616dd4004d0db9313 X-Archives-Salt: 30bbe8f1-5040-4248-bc52-dcb4e950d990 X-Archives-Hash: 2923cfd84e058e5044db44f99baa0c91 --00151758a6e616dd4004d0db9313 Content-Type: text/plain; charset=ISO-8859-1 > > >> > So if I have 2 physical CPU's with 4 cores each and I enable SMP, I'm > > >> > using > > >> > 8 cores? Can NUMA be either enabled or disabled when using more than > > >> > one > > >> > physical CPU, or is it required? > > >> > > >> > > >> NUMA is a hardware architecture. It's how you access memory on a > > >> hardware level: NUMA = Non Uniform Memory Access vs a UMA architecture > > >> of typical (old/legacy) SMP systems (UMA = Uniform Memory Access). > > >> > > >> In a UMA system, all the memory belongs to all the sockets. In a NUMA > > >> system, each socket has it's "own" local memory. In modern (x86-64) > > >> processors, each socket has it's own memory controller so each socket > > >> controls its own local memory. If one socket runs out of memory it can > > >> ask another socket to lend him some memory. In a UMA system, no socket > > >> has to ask since memory is global and belongs to all sockets so if one > > >> socket uses up all the memory ... the rest "starve". In NUMA, there's > > >> more control over who uses what (be it cores or RAM). > > >> > > >> If you have a modern dual or quad (or higher #) socket system ... > > >> you've got NUMA architecture and you can't get rid of it, it's > > >> hardware, not software. > > > > > > So I must enable CONFIG_NUMA for more than one physical CPU, and disable it > > > for only one physical CPU? > > > > > > Yup. But ... Why would you want to disable a socket (CPU)? If you > > disable a socket (CPU) ... you lose the memory attached to that socket > > (CPU) not to mention you lose those cores ;) > > Sure but it sounds like if my system only has one CPU socket, CONFIG_NUMA should be disabled. I read this in make menuconfig: "The kernel will try to allocate memory used by a CPU on the local memory controller of the CPU and add some more NUMA awareness to the kernel. For 64-bit this is recommended if the system is Intel Core i7 (or later), AMD Opteron, or EM64T NUMA." To be sure I have this right, I should disable CONFIG_NUMA on any system with a single physical CPU, even if it's an AMD Opteron? - Grant --00151758a6e616dd4004d0db9313 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable > > >> > So if I have 2 physical CPU's with 4 cores each= and I enable SMP, I'm
> > >> > using
> > &g= t;> > 8 cores? =A0Can NUMA be either enabled or disabled when using m= ore than
> > >> > one
> > >> > physical CPU, or is = it required?
> > >>
> > >>
> > >&= gt; NUMA is a hardware architecture. It's how you access memory on a > > >> hardware level: NUMA =3D Non Uniform Memory Access vs a = UMA architecture
> > >> of typical (old/legacy) SMP systems = (UMA =3D Uniform Memory Access).
> > >>
> > >>= ; In a UMA system, all the memory belongs to all the sockets. In a NUMA
> > >> system, each socket has it's "own" local m= emory. In modern (x86-64)
> > >> processors, each socket has= it's own memory controller so each socket
> > >> contro= ls its own local memory. If one socket runs out of memory it can
> > >> ask another socket to lend him some memory. In a UMA sys= tem, no socket
> > >> has to ask since memory is global and = belongs to all sockets so if one
> > >> socket uses up all t= he memory ... the rest "starve". In NUMA, there's
> > >> more control over who uses what (be it cores or RAM).> > >>
> > >> If you have a modern dual or quad= (or higher #) socket system ...
> > >> you've got NUMA = architecture and you can't get rid of it, it's
> > >> hardware, not software.
> > >
> > &= gt; So I must enable CONFIG_NUMA for more than one physical CPU, and disabl= e it
> > > for only one physical CPU?
> >
> >=
> > Yup. But ... Why would you want to disable a socket (CPU)? If you=
> > disable a socket (CPU) ... you lose the memory attached to th= at socket
> > (CPU) not to mention you lose those cores ;)
>
> Sure but it sounds like if my system only has one CPU socket, = CONFIG_NUMA should be disabled.

I read this in make menuconfig:
=
"The kernel will try to allocate memory used by a CPU o= n the=A0local memory controller of the CPU and add some more=A0NUMA awarene= ss to the kernel.=A0For 64-bit this is recommended if the system is Intel C= ore i7=A0(or later), AMD Opteron, or EM64T NUMA."

To be sure I have this right, I should disable CO= NFIG_NUMA on any system with a single physical CPU, even if it's an AMD= Opteron?

- Grant
--00151758a6e616dd4004d0db9313--