qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "Gabriel L. Somlo" <gsomlo@gmail.com>
To: qemu-devel@nongnu.org
Cc: seabios@seabios.org, agraf@suse.de, armbru@redhat.com,
	alex.williamson@redhat.com, kevin@koconnor.net,
	kraxel@redhat.com, imammedo@redhat.com, lersek@redhat.com
Subject: Re: [Qemu-devel] E820 (Re: [v4 PATCH 00/12] SMBIOS: build full tables in QEMU)
Date: Wed, 26 Mar 2014 22:45:44 -0400	[thread overview]
Message-ID: <20140327024544.GA2693@crash.ini.cmu.edu> (raw)
In-Reply-To: <20140326195849.GD1543@ERROL.INI.CMU.EDU>

On Wed, Mar 26, 2014 at 03:58:50PM -0400, Gabriel L. Somlo wrote:
> On Tue, Mar 18, 2014 at 07:23:17PM -0400, Gabriel L. Somlo wrote:
> > At this point, can anyone with access to a real, physical, NUMA
> > system dump the smbios tables with dmidecode and post them here?
> > I think that would be very informative.
> 
> So I thrashed around a bit trying to find a real NUMA box,
> and found a Dell R410 whose BIOS claims to support NUMA by
> disabling the "Node Interleaving" option

So, flipping that option on and off does indeed switch the system
between NUMA and UMA modes. Running "numactl -H" in UMA mode gets us
this output:

    available: 1 nodes (0)
    node 0 cpus: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21
    22 23
    node 0 size: 131059 MB
    node 0 free: 127898 MB
    node distances:
    node   0 
      0:  10 

In NUMA mode, we get this:

    available: 2 nodes (0-1)
    node 0 cpus: 0 2 4 6 8 10 12 14 16 18 20 22
    node 0 size: 65536 MB
    node 0 free: 64047 MB
    node 1 cpus: 1 3 5 7 9 11 13 15 17 19 21 23
    node 1 size: 65523 MB
    node 1 free: 63841 MB
    node distances:
    node   0   1 
      0:  10  20 
      1:  20  10 

The "dmidecode" output stays unchanged between UMA and NUMA
modes (showing only memory tables, types 16-19, and there is NO
type 20):

    Handle 0x1000, DMI type 16, 15 bytes
    Physical Memory Array
            Location: System Board Or Motherboard
            Use: System Memory
            Error Correction Type: Multi-bit ECC
            Maximum Capacity: 128 GB
            Error Information Handle: Not Provided
            Number Of Devices: 8

    Handle 0x1100, DMI type 17, 28 bytes
    Memory Device
            Array Handle: 0x1000
            Error Information Handle: Not Provided
            Total Width: 72 bits
            Data Width: 64 bits
            Size: 16384 MB
            Form Factor: DIMM
            Set: 1
            Locator: DIMM_A1 
            Bank Locator: Not Specified
            Type: DDR3
            Type Detail: Synchronous Registered (Buffered)
            Speed: 1066 MHz
            Manufacturer: 00CE00B380CE
            Serial Number: 44056D5E
            Asset Tag: 01105061
            Part Number: M393B2K70CM0-YF8  
            Rank: 4

    Handle 0x1101, DMI type 17, 28 bytes
    Handle 0x1102, DMI type 17, 28 bytes
    Handle 0x1103, DMI type 17, 28 bytes
    Handle 0x1109, DMI type 17, 28 bytes
    Handle 0x110A, DMI type 17, 28 bytes
    Handle 0x110B, DMI type 17, 28 bytes
    Handle 0x110C, DMI type 17, 28 bytes
            /* all of them similar to 0x1100 above [GLS] */

    Handle 0x1300, DMI type 19, 15 bytes
    Memory Array Mapped Address
            Starting Address: 0x00000000000
            Ending Address: 0x000BFFFFFFF
            Range Size: 3 GB
            Physical Array Handle: 0x1000
            Partition Width: 2

    Handle 0x1301, DMI type 19, 15 bytes
    Memory Array Mapped Address
            Starting Address: 0x00100000000
            Ending Address: 0x0203FFFFFFF
            Range Size: 125 GB
            Physical Array Handle: 0x1000
            Partition Width: 2

The output of "dmesg | grep -i e820" remains unchanged between UMA and
NUMA modes:

    e820: BIOS-provided physical RAM map:
    BIOS-e820: [mem 0x0000000000000000-0x000000000009ffff] usable
    BIOS-e820: [mem 0x0000000000100000-0x00000000bf378fff] usable
    BIOS-e820: [mem 0x00000000bf379000-0x00000000bf38efff] reserved
    BIOS-e820: [mem 0x00000000bf38f000-0x00000000bf3cdfff] ACPI data
    BIOS-e820: [mem 0x00000000bf3ce000-0x00000000bfffffff] reserved
    BIOS-e820: [mem 0x00000000e0000000-0x00000000efffffff] reserved
    BIOS-e820: [mem 0x00000000fe000000-0x00000000ffffffff] reserved
    BIOS-e820: [mem 0x0000000100000000-0x000000203fffffff] usable
    e820: update [mem 0x00000000-0x0000ffff] usable ==> reserved
    e820: remove [mem 0x000a0000-0x000fffff] usable
    e820: last_pfn = 0x2040000 max_arch_pfn = 0x400000000
    e820: update [mem 0xc0000000-0xffffffff] usable ==> reserved
    e820: last_pfn = 0xbf379 max_arch_pfn = 0x400000000
    e820: [mem 0xc0000000-0xdfffffff] available for PCI devices
    PCI: MMCONFIG at [mem 0xe0000000-0xefffffff] reserved in E820
    e820: reserve RAM buffer [mem 0xbf379000-0xbfffffff]

So, even in NUMA mode, there still appear to be only two contiguous
E820_RAM type entries in the "sanitized" e820 table (the regions
marked "usable" appear to be adjacent). And the E820_RAM contiguous
regions are not per-node or anything like that. Not that this is to
be taken as the "One True Way", but still, it's a data point.

Anyhow, my original question/worry ("Oonce you create Type17 DIMMs
from all the RAM, and Type19 regions for each E820_RAM type entry,
how do you tie them together with Type20s ?") has been answered
("You just don't" :) )

Just figured I'd share this, maybe it can be useful to someone else
besides me...

Cheers,
--Gabriel

      parent reply	other threads:[~2014-03-27  2:46 UTC|newest]

Thread overview: 50+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-03-18 23:23 [Qemu-devel] [v4 PATCH 00/12] SMBIOS: build full tables in QEMU Gabriel L. Somlo
2014-03-18 23:23 ` [Qemu-devel] [v4 PATCH 01/12] SMBIOS: Rename smbios_set_type1_defaults() for more general use Gabriel L. Somlo
2014-03-18 23:23 ` [Qemu-devel] [v4 PATCH 02/12] SMBIOS: Use macro to set smbios defaults Gabriel L. Somlo
2014-03-18 23:23 ` [Qemu-devel] [v4 PATCH 03/12] SMBIOS: Use bitmaps to check for smbios table collisions Gabriel L. Somlo
2014-03-18 23:23 ` [Qemu-devel] [v4 PATCH 04/12] SMBIOS: Add code to build full smbios tables; build type 2 table Gabriel L. Somlo
2014-03-18 23:23 ` [Qemu-devel] [v4 PATCH 05/12] SMBIOS: Build full tables for types 0 and 1 Gabriel L. Somlo
2014-03-18 23:23 ` [Qemu-devel] [v4 PATCH 06/12] SMBIOS: Remove unused code for passing individual fields to bios Gabriel L. Somlo
2014-03-18 23:23 ` [Qemu-devel] [v4 PATCH 07/12] SMBIOS: Build full type 3 table Gabriel L. Somlo
2014-03-18 23:23 ` [Qemu-devel] [v4 PATCH 08/12] SMBIOS: Build full type 4 tables Gabriel L. Somlo
2014-03-18 23:23 ` [Qemu-devel] [v4 PATCH 09/12] SMBIOS: Build full smbios memory tables (type 16, 17, 19, and 20) Gabriel L. Somlo
2014-03-18 23:23 ` [Qemu-devel] [v4 PATCH 10/12] SMBIOS: Build full tables for type 32 and 127 Gabriel L. Somlo
2014-03-18 23:23 ` [Qemu-devel] [v4 PATCH 11/12] SMBIOS: Update all table definitions to smbios spec v2.3 Gabriel L. Somlo
2014-03-18 23:23 ` [Qemu-devel] [v4 PATCH 12/12] SMBIOS: Remove SeaBIOS compatibility quirks Gabriel L. Somlo
2014-03-26 19:58 ` [Qemu-devel] E820 (Re: [v4 PATCH 00/12] SMBIOS: build full tables in QEMU) Gabriel L. Somlo
2014-03-26 22:36   ` Kevin O'Connor
2014-03-31 20:18     ` Gabriel L. Somlo
2014-04-01  8:40       ` Laszlo Ersek
2014-04-01 14:39         ` Kevin O'Connor
2014-04-01 15:47           ` Laszlo Ersek
2014-04-01 18:47             ` Gabriel L. Somlo
2014-04-01 20:28               ` Kevin O'Connor
2014-04-01 21:28                 ` Gabriel L. Somlo
2014-04-01 21:44                   ` Laszlo Ersek
2014-04-01 22:00                     ` Kevin O'Connor
2014-04-01 22:35                       ` Laszlo Ersek
2014-04-02 12:38                         ` Gabriel L. Somlo
2014-04-02 13:39                           ` Laszlo Ersek
2014-04-05  2:48                         ` Kevin O'Connor
2014-04-02 15:07                     ` Gerd Hoffmann
2014-04-02 17:01                       ` Gabriel L. Somlo
2014-04-03  1:57                         ` Gabriel L. Somlo
2014-04-03  9:42                           ` Laszlo Ersek
2014-04-03 13:32                             ` Gabriel L. Somlo
2014-04-03 13:56                               ` Laszlo Ersek
2014-04-07  6:50                               ` Gerd Hoffmann
2014-04-07  6:47                             ` Gerd Hoffmann
2014-04-01 21:48                   ` Kevin O'Connor
2014-04-02 15:04                 ` Gerd Hoffmann
2014-04-05  0:34                   ` Kevin O'Connor
2014-04-05  1:15                     ` Gabriel L. Somlo
2014-04-05  2:26                       ` Kevin O'Connor
2014-04-07  7:09                         ` Gerd Hoffmann
2014-04-07 14:14                           ` Kevin O'Connor
2014-04-07 14:33                             ` Laszlo Ersek
2014-04-07 14:49                             ` Gabriel L. Somlo
2014-04-07 15:23                               ` Kevin O'Connor
2014-04-07 18:05                                 ` Gabriel L. Somlo
2014-04-07 18:57                                   ` Kevin O'Connor
2014-04-08 13:51                                     ` Gabriel L. Somlo
2014-03-27  2:45   ` Gabriel L. Somlo [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20140327024544.GA2693@crash.ini.cmu.edu \
    --to=gsomlo@gmail.com \
    --cc=agraf@suse.de \
    --cc=alex.williamson@redhat.com \
    --cc=armbru@redhat.com \
    --cc=imammedo@redhat.com \
    --cc=kevin@koconnor.net \
    --cc=kraxel@redhat.com \
    --cc=lersek@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=seabios@seabios.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).