From wollman@zfsnfs.csail.mit.edu  Fri Mar  9 21:30:13 2012
Return-Path: <wollman@zfsnfs.csail.mit.edu>
Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52])
	by hub.freebsd.org (Postfix) with ESMTP id 77EB1106566B
	for <FreeBSD-gnats-submit@freebsd.org>; Fri,  9 Mar 2012 21:30:13 +0000 (UTC)
	(envelope-from wollman@zfsnfs.csail.mit.edu)
Received: from zfsnfs.csail.mit.edu (zfsnfs.csail.mit.edu [128.30.113.117])
	by mx1.freebsd.org (Postfix) with ESMTP id 3BCDD8FC08
	for <FreeBSD-gnats-submit@freebsd.org>; Fri,  9 Mar 2012 21:30:13 +0000 (UTC)
Received: from zfsnfs.csail.mit.edu (localhost [127.0.0.1])
	by zfsnfs.csail.mit.edu (8.14.5/8.14.5) with ESMTP id q29LU6pL043521
	for <FreeBSD-gnats-submit@freebsd.org>; Fri, 9 Mar 2012 16:30:06 -0500 (EST)
	(envelope-from wollman@zfsnfs.csail.mit.edu)
Received: (from wollman@localhost)
	by zfsnfs.csail.mit.edu (8.14.5/8.14.5/Submit) id q29LU52n043520;
	Fri, 9 Mar 2012 16:30:05 -0500 (EST)
	(envelope-from wollman)
Message-Id: <201203092130.q29LU52n043520@zfsnfs.csail.mit.edu>
Date: Fri, 9 Mar 2012 16:30:05 -0500 (EST)
From: Garrett Wollman <wollman@csail.mit.edu>
Reply-To: Garrett Wollman <wollman@csail.mit.edu>
To: FreeBSD-gnats-submit@freebsd.org
Cc:
Subject: processor topology should be exported in more obvious format
X-Send-Pr-Version: 3.113
X-GNATS-Notify:

>Number:         165893
>Category:       kern
>Synopsis:       [kernel] [request] processor topology should be exported in more obvious format
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    freebsd-bugs
>State:          open
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          change-request
>Submitter-Id:   current-users
>Arrival-Date:   Fri Mar 09 21:40:06 UTC 2012
>Closed-Date:    
>Last-Modified:  Sat Mar 10 06:08:19 UTC 2012
>Originator:     Garrett Wollman
>Release:        FreeBSD 9.0-RELEASE amd64
>Organization:
MIT Computer Science & Artificial Intelligence Lab
>Environment:
System: FreeBSD zfsnfs.csail.mit.edu 9.0-RELEASE FreeBSD 9.0-RELEASE #3 r232145M: Sun Feb 26 20:00:10 EST 2012 wollman@zfsnfs.csail.mit.edu:/usr/obj/usr/src/sys/ZFSNFS amd64

>Description:

Currently, the sysctl variable hw.ncpu gives the number of logical
processors.  kern.sched.topology_spec gives a hard-to-parse XML
description of the system topology (is this ULE-only or 4BSD as
well?).  Grepping /var/run/dmesg.boot will tell you the number of
sockets, cores, and threads without having to parse XML.  It would be
preferable if these values were reflected in sysctl variables (in,
take your pick, the kern.sched, hw, machdep, or dev.cpu tree) so
programs don't have to parse XML or depend on being able to read
dmesg.boot.

>How-To-Repeat:

>Fix:

Sprinkle some SYSCTL_RDINT() macros into ${ARCH}/mp_machdep.c.

>Release-Note:
>Audit-Trail:

From: Andriy Gapon <avg@icyb.net.ua>
To: bug-followup@FreeBSD.org, wollman@csail.mit.edu
Cc:  
Subject: Re: kern/165893: processor topology should be exported in more obvious
 format
Date: Sat, 10 Mar 2012 00:32:06 +0200

 OTOH, it would probably also make sense to not assume that a topology is always
 uniform.  There could be a different number of (online) cores per package, etc.
 
 BTW, you can try to use devel/hwloc (http://www.open-mpi.org/projects/hwloc/) -
 it provides convenience and portability.
 
 But I agree that this is a valid PR as our kernel could do a better job at
 providing topological information to userland in more ready form.
 
 -- 
 Andriy Gapon

From: Garrett Wollman <wollman@csail.mit.edu>
To: Andriy Gapon <avg@icyb.net.ua>
Cc: bug-followup@FreeBSD.org
Subject: Re: kern/165893: processor topology should be exported in more obvious
 format
Date: Fri, 9 Mar 2012 18:10:22 -0500

 <<On Sat, 10 Mar 2012 00:32:06 +0200, Andriy Gapon <avg@icyb.net.ua> said:
 
 > OTOH, it would probably also make sense to not assume that a topology is always
 > uniform.  There could be a different number of (online) cores per package, etc.
 
 At a minimum, having separate "processors", "cores", and "threads"
 sysctl variables would ease hardware identification, and there's no
 need to assume that they are uniform in order to make use of this.
 
 -GAWollman
 
>Unformatted:
