From: Cliff Wickman <cpw@sgi.com>
To: Tim Pepper <lnxninja@linux.vnet.ibm.com>
Cc: linux-numa@vger.kernel.org, andi@firstfloor.org
Subject: Re: [PATCH 0 of 5] RFC: Handling of sparse, memoryless, and cpuless nodes
Date: Mon, 4 Oct 2010 09:16:26 -0500 [thread overview]
Message-ID: <20101004141626.GA900@sgi.com> (raw)
In-Reply-To: <20100922180347.GC31877@tpepper-t61p.dolavim.us>
Thanks, Tim.
(Yes, I'm still here. Just been on vacation since you sent your patches.)
I tested your patches with the usual test suite, on an 8-node ia64 and
on an 8-node x86_64 (uv).
Now available at ftp://oss.sgi.com/www/projects/libnuma/download/
as numactl-2.0.6-rc1.tar.gz
-Cliff
On Wed, Sep 22, 2010 at 11:03:47AM -0700, Tim Pepper wrote:
> In response to a bug report where 'numactl --hardware' was segfaulting
> with distro 2.0.3 version I've dug into the current state of
> libnuma/numactl after not having looked at it in quite some time. The
> following series of patches resulted and hopefully clarifies things a bit
> for the next person who comes along and accounts for the possibility of
> sparsely numbered, memoryless and cpuless nodes in 'numactl --hardware'.
> There are certainly some things in the patches that aren't quite optimal
> and other things I saw that I didn't try to tackle (eg: there is a lot
> of seeming inconsistency around the different "all" node pointers),
> but the updated code works for me and I was trying to limit changes to
> not start driving in the direction of a v3 library (or hwloc?).
>
> The first 4 patches are relatively minor cleanups.
>
> The bulk is in patch 5 which then deals with better handling sparse node
> numbering and fixes parse_numbers() in particular which was experiencing
> a buffer overflow in the face of this topology:
>
> available: 2 nodes (0,3)
> node 0 cpus: none
> node 0 size: 0 MB
> node 0 free: 0 MB
> node 3 cpus: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
> node 3 size: 15360 MB
> node 3 free: 12524 MB
> node distances:
> node 0 3
> 0: 10 40
> 3: 40 10
>
> I've tested the changes on "interesting" topology hardware to which I
> have access, but would greatly appreciate if others might do similar.
>
> --
> Tim Pepper <lnxninja@linux.vnet.ibm.com>
> IBM Linux Technology Center
> --
> To unsubscribe from this list: send the line "unsubscribe linux-numa" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Cliff Wickman
SGI
cpw@sgi.com
(651) 683-3824
prev parent reply other threads:[~2010-10-04 14:16 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-09-22 18:03 [PATCH 0 of 5] RFC: Handling of sparse, memoryless, and cpuless nodes Tim Pepper
2010-10-04 14:16 ` Cliff Wickman [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=20101004141626.GA900@sgi.com \
--to=cpw@sgi.com \
--cc=andi@firstfloor.org \
--cc=linux-numa@vger.kernel.org \
--cc=lnxninja@linux.vnet.ibm.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.