This doesn't seem to apply to all SMP systems (or is it kernel version?):
kernel: 2.6.12-10-686-smp
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 8
model name : Pentium III (Coppermine)
stepping : 1
cpu MHz : 731.523
cache size : 256 KB
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 2
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge
mca cmov pat pse36 mmx fxsr sse
bogomips : 1449.98
processor : 1
vendor_id : GenuineIntel
cpu family : 6
model : 8
model name : Pentium III (Coppermine)
stepping : 1
cpu MHz : 731.523
cache size : 256 KB
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 2
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge
mca cmov pat pse36 mmx fxsr sse
bogomips : 1462.27
As for the code, perhaps these changes to your patch would provide with
the required results:
#define UNIPROCESSOR 1
/* dont_count_ht_cpus indicates an option has been set in the config */
if ((n = sysconf(_SC_NPROCESSORS_ONLN) > UNIPROCESSOR &&
dont_count_ht_cpus) {
/* examine /proc/cpuinfo */
cores_in_cpuinfo = ....
}
/* if cores_in_cpuinfo reports 0, we're on a system which doesn't report
core_id */
if (cores_in_cpuinfo)
return (int) cores_in_cpuinfo;
else
return (int) n;
Also, MAX_CPUS is a hard-coded scalability limit. To avoid that maybe
you could just grab the last "processor" entry and assign an array of
that size. This would also cover hot-plugging CPUs, but might involve a
race in such a setup. What do you guys think?
Cheers,
Alex
James Mcininch wrote:
>
> On SMP machines, each entry in /proc/cpuinfo reports 'core id'
> and 'physical id' in addition to 'processor'. The number of
> 'processor' entries is cpu_count_virtual. The number of distinct
> 'physical id' entries is the number of CPU packages installed
> on the motherboard. The number of distinct 'core id' entries is
> the number of CPU cores.
>
> On non-SMP machines, each entry in /proc/cpuinfo reports
> 'cpu count' (if applicable) to denote how many 'processor'
> entries exist for the one physical CPU (i.e., if 'cpu count' is
> 2, that processor entry is 1/2 of the entries reported for that
> 1 physical CPU). So the sum of 'processor' entries divided by
> their respective 'cpu count' values is the cpu_count_cores and
> cpu_count_physical, and the number of 'processor' entries is the
> cpu_count_virtual.
>
> It's a little daft, but that's the way it seems to work.
>
> My original patch submission didn't handle the non-SMP case --
> I need to fix that.
>
>
> <[EMAIL PROTECTED]> wrote on 03/01/2006 12:26:47 PM:
>
> > From the look of /proc/stat and /proc/cpuinfo in cygwin, I am
> > not sure how you resolve between virtual and real processors.
> > Am I missing something?
> >
> > regards,
> > richard
> >
> > cpu 91283593 0 24818640 2641219155
> > cpu0 33563843 0 13294859 1331802093
> > cpu1 57719750 0 11523781 1309417062
> > page 28101525 3278915
> > swap 28101525 3042074
> > intr 1021797193
> > ctxt 2106977704
> > btime 1139854968
> >
> >
> > processor : 0
> > vendor_id : GenuineIntel
> > type : primary processor
> > cpu family : 15
> > model : 2
> > model name : Intel(R) Pentium(R) 4 CPU 2.80GHz
> > stepping : 9
> > brand id : 9
> > cpu count : 2
> > apic id : 0
> > cpu MHz : 2793
> > fpu : yes
> > flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge
> > mca cmov pat pse36 clfl dtes acpi mmx fxsr sse
> > e2 ss htt tmi pbe cid
> > processor : 1
> > vendor_id : GenuineIntel
> > type : primary processor
> > cpu family : 15
> > model : 2
> > model name : Intel(R) Pentium(R) 4 CPU 2.80GHz
> > stepping : 9
> > brand id : 9
> > cpu count : 2
> > apic id : 1
> > cpu MHz : 2793
> > fpu : yes
> > flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge
> > mca cmov pat pse36 clfl dtes acpi mmx fxsr sse
> > e2 ss htt tmi pbe cid
> >
> > -----Original Message-----
> > From: [EMAIL PROTECTED]
> > [mailto:[EMAIL PROTECTED] On Behalf Of
> > Jason A. Smith
> > Sent: 01 March 2006 15:42
> > To: James Mcininch
> > Cc: Ganglia Developers
> > Subject: Re: [Ganglia-developers] hyperthreading & cpu_num patch.
> >
> >
> > Hi James,
> >
> > As you mentioned in your bug report:
> >
> > http://bugzilla.ganglia.info/cgi-bin/bugzilla/show_bug.cgi?id=84
> >
> > This has been discussed several times in the mailing lists, like this
> > one last year:
> >
> > http://sourceforge.net/mailarchive/forum.php?forum_id=7186&max_rows=25&s
> > tyle=threaded&viewmonth=200502
> >
> > But as the discussion last year confirms, different people might want it
> > to work in different ways. The best solution would probably be to patch
> > gmond to report both the number of real and virtual (hyperthreaded) CPUs
> > and have a config option in the webfrontend to display the load based on
> > one of the two CPU counts.
> >
> > ~Jason
> >
> >
> > On Wed, 2006-03-01 at 09:40 -0500, James Mcininch wrote:
> > >
> > > I want to bring attention to Bugzilla item 84 -- a patch submitted to
> > > fix improper reporting of cpu_num on hyperthreaded Intel processors.
> > >
> > > The patch causes it to report the number of CPU cores rather than the
> > > number of virtual CPUs.
> > >
> > --
> > /------------------------------------------------------------------\
> > | Jason A. Smith Email: [EMAIL PROTECTED] |
> > | Atlas Computing Facility, Bldg. 510M Phone: (631)344-4226 |
> > | Brookhaven National Lab, P.O. Box 5000 Fax: (631)344-7616 |
> > | Upton, NY 11973-5000 |
> > \------------------------------------------------------------------/
> >
> >
> >
> >
> > -------------------------------------------------------
> > This SF.Net email is sponsored by xPML, a groundbreaking scripting
> > language that extends applications into web and mobile media. Attend the
> > live webcast and join the prime developer group breaking into this new
> > coding territory!
> > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
> > _______________________________________________
> > Ganglia-developers mailing list Ganglia-developers@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/ganglia-developers
> >
> >
> > ------------------------------------------------------------------------
> > For more information about Barclays Capital, please
> > visit our web site at http://www.barcap.com.
> >
> >
> > Internet communications are not secure and therefore the Barclays
> > Group does not accept legal responsibility for the contents of this
> > message. Although the Barclays Group operates anti-virus programmes,
> > it does not accept responsibility for any damage whatsoever that is
> > caused by viruses being passed. Any views or opinions presented are
> > solely those of the author and do not necessarily represent those of
> the
> > Barclays Group. Replies to this email may be monitored by the Barclays
> > Group for operational or business reasons.
> >
> > ------------------------------------------------------------------------
> >
