Re: [Ganglia-general] hyperthreading
I know how to enable/disable HT at the OS level. What I want is for _ganglia_ to know about hyperthreading, and to report the true number of processors, or at the very least report hyperthreading is present, and then let gmetad/ the webapp to take this into account. There are patches out there for this ... my question is whether ganglia addresses this concern (which seems a common one), and whether it can be configured in gmond.conf or whereever. On Feb 15, 2005, at 5:37 PM, Eric Whiting wrote: I assume you want HT... If you don't want HT you can 1) change a setting in most bioses, or 2) use the noht option at bot, or 3) compile a kernel without HT support. eric Robert E. Parrott wrote: Is there a way to make ganglia hyperthread - aware in v3.0? We have a cluster of dual Xeons with hyperthreading, which ganglia reports as 4 processes. This is annoying when using the web frontend, since full load appears to only be 1/2 load, and people think there are twice as many CPUs available. With 2.5.7, I hacked the code using a patch from OSC to only report 2 processor per real processor when hyperthreading was found enabled. However, in 3.0 this is not enabled, so I've backed down to 2.5.7 again. Is there a reason this kind of patch is not in place? Are there options I;m not aware of in the config files? thanx, rob --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click ___ Ganglia-general mailing list Ganglia-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ganglia-general
Re: [Ganglia-general] hyperthreading
On Tue, Feb 15, 2005 at 05:27:53PM -0500, Robert E. Parrott wrote: > Is there a way to make ganglia hyperthread - aware in v3.0? > > We have a cluster of dual Xeons with hyperthreading, which ganglia > reports as 4 processes. This is annoying when using the web frontend, > since full load appears to only be 1/2 load, and people think there are > twice as many CPUs available. > > With 2.5.7, I hacked the code using a patch from OSC to only report 2 > processor per real processor when hyperthreading was found enabled. > > However, in 3.0 this is not enabled, so I've backed down to 2.5.7 again. > > Is there a reason this kind of patch is not in place? Are there options > I;m not aware of in the config files? There is no sensible way to do this that will always work. The problem is that some users will want the current behavior and other will certainly not. It depends on their applications. A small, but non-zero set of applications exists for which HTT really is nearly as good as two CPUs. The real issue is that a number of cpus variable is no where near sufficient to represent the issues involved in representing the hierarchy of CPU like things on your machine. It's actually the case that as long as the FSB speeds match, there's no reason why your CPUs even need to be running at the same internal clock rate, on the current x86 architecture. I think a configuration option for gmond to divide the number of CPUs by something before reporting would be a decent, low effort method of allowing people to report what they want. -- Brooks -- Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 pgpwIoBWIgyYI.pgp Description: PGP signature
Re: [Ganglia-general] hyperthreading
Brooks Davis wrote: On Tue, Feb 15, 2005 at 05:27:53PM -0500, Robert E. Parrott wrote: Is there a way to make ganglia hyperthread - aware in v3.0? We have a cluster of dual Xeons with hyperthreading, which ganglia reports as 4 processes. This is annoying when using the web frontend, since full load appears to only be 1/2 load, and people think there are twice as many CPUs available. With 2.5.7, I hacked the code using a patch from OSC to only report 2 processor per real processor when hyperthreading was found enabled. However, in 3.0 this is not enabled, so I've backed down to 2.5.7 again. Is there a reason this kind of patch is not in place? Are there options I;m not aware of in the config files? There is no sensible way to do this that will always work. The problem is that some users will want the current behavior and other will certainly not. It depends on their applications. A small, but non-zero set of applications exists for which HTT really is nearly as good as two CPUs. The real issue is that a number of cpus variable is no where near sufficient to represent the issues involved in representing the hierarchy of CPU like things on your machine. It's actually the case that as long as the FSB speeds match, there's no reason why your CPUs even need to be running at the same internal clock rate, on the current x86 architecture. I think a configuration option for gmond to divide the number of CPUs by something before reporting would be a decent, low effort method of allowing people to report what they want. -- Brooks I have not looked at the method ganglia uses to gather the cpu count on linux, but I do know that on 2.4.21 linux, /proc/cpuinfo shows hyperthreaded cpus as sharing the same physical id and runqueue numbers. I agree with Brooks that this should be configurable, but I do not recommend dividing number of cpus, rather count the unique physical ids. I also agree that just reducing the number of cpus doesn't represent the situation correctly. If you have 2 running process, one heavy usage, one light usage, on a single HT cpu, with ganglia showing 1 cpu, your load report will be inaccurate. You will have crossed the red line on the chart but not in reality. tricksy Ian
Re: [Ganglia-general] hyperthreading
On Tue, Feb 15, 2005 at 06:38:09PM -0700, Ian Cunningham wrote: > Brooks Davis wrote: > > >On Tue, Feb 15, 2005 at 05:27:53PM -0500, Robert E. Parrott wrote: > > > > > >>Is there a way to make ganglia hyperthread - aware in v3.0? > >> > >>We have a cluster of dual Xeons with hyperthreading, which ganglia > >>reports as 4 processes. This is annoying when using the web frontend, > >>since full load appears to only be 1/2 load, and people think there are > >>twice as many CPUs available. > >> > >>With 2.5.7, I hacked the code using a patch from OSC to only report 2 > >>processor per real processor when hyperthreading was found enabled. > >> > >>However, in 3.0 this is not enabled, so I've backed down to 2.5.7 again. > >> > >>Is there a reason this kind of patch is not in place? Are there options > >>I;m not aware of in the config files? > >> > >> > > > >There is no sensible way to do this that will always work. The > >problem is that some users will want the current behavior and other > >will certainly not. It depends on their applications. A small, but > >non-zero set of applications exists for which HTT really is nearly as > >good as two CPUs. The real issue is that a number of cpus variable is > >no where near sufficient to represent the issues involved in representing > >the hierarchy of CPU like things on your machine. It's actually the > >case that as long as the FSB speeds match, there's no reason why your > >CPUs even need to be running at the same internal clock rate, on the > >current x86 architecture. > > > >I think a configuration option for gmond to divide the number of CPUs by > >something before reporting would be a decent, low effort method of > >allowing people to report what they want. > > > I have not looked at the method ganglia uses to gather the cpu count on > linux, but I do know that on 2.4.21 linux, /proc/cpuinfo shows > hyperthreaded cpus as sharing the same physical id and runqueue numbers. > I agree with Brooks that this should be configurable, but I do not > recommend dividing number of cpus, rather count the unique physical ids. Not all OSes provide the ability to show this information. Hence my suggestion to simply allow people to divide. An option to only show physical CPUs could also be useful, but would not be implementable in all cases. -- Brooks -- Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 pgpOeEN17QTIS.pgp Description: PGP signature
Re: [Ganglia-general] hyperthreading
Brooks Davis <[EMAIL PROTECTED]> writes: > The real issue is that a number of cpus variable is no where near > sufficient to represent the issues involved in representing the > hierarchy of CPU like things on your machine. Exactly. And with multi-core CPU:s coming out, it's going to get real hard to define what a "physical CPU" is. -- Leif Nixon -Systems expert National Supercomputer Centre- Linkoping University
Re: [Ganglia-general] hyperthreading
Leif Nixon wrote: Brooks Davis <[EMAIL PROTECTED]> writes: The real issue is that a number of cpus variable is no where near sufficient to represent the issues involved in representing the hierarchy of CPU like things on your machine. Exactly. And with multi-core CPU:s coming out, it's going to get real hard to define what a "physical CPU" is. Then how about just seperating all CPU reporting facilities into a seperate module that can be configured outside of ganglia itself? That way, users can prepare whatever relevant statistic is appropriate for their needs. - Marcel
Re: [Ganglia-general] hyperthreading
Robert E. Parrott wrote: Is there a way to make ganglia hyperthread - aware in v3.0? We have a cluster of dual Xeons with hyperthreading, which ganglia reports as 4 processes. This is annoying when using the web frontend, since full load appears to only be 1/2 load, and people think there are twice as many CPUs available. I'm a little confused as to why you want this. If you have dual processors with HT enabled, then a full load is four processes running, which would give you a load average of 4.0. And since ganglia will indicate that a load of 4.0 is 'full load', then it currently does the right thing. So I guess my question is, how is 4 processes running on a dual proc machine with HT not full load? And if you want full load to be 2 processes running, why are you using HT?
Re: [Ganglia-general] hyperthreading
On Wed, 16 Feb 2005 at 8:42am, Sean Dilda wrote > I'm a little confused as to why you want this. If you have dual > processors with HT enabled, then a full load is four processes running, > which would give you a load average of 4.0. And since ganglia will > indicate that a load of 4.0 is 'full load', then it currently does the > right thing. If all 4 of those processes are compute intensive, then they're going to run slower in parallel then they would in serial sets of 2. Those virtual processors do share physical hardware, after all. > So I guess my question is, how is 4 processes running on a dual proc > machine with HT not full load? And if you want full load to be 2 > processes running, why are you using HT? Some may run HT in the hopes that with 2 compute intensive tasks running, the "idle" virtual procs will take care of the bookkeeping and other minimal load stuff the kernel's doing all the time without slowing down the compute tasks. I thought of running that way, but (as we all know) users are easily confused and I didn't think the possible benefits worth the pain of trying to educate them. ;) -- Joshua Baker-LePain Department of Biomedical Engineering Duke University
Re: [Ganglia-general] hyperthreading
Maybe I'm missing something here but full load is NOT 4 processes with hyperthreading. Hyperthreading is a mixed bag, and while great for Desktop use, for compute & memory bandwidth intensive jobs, can be a real drain, because both processes are computing for the same cache. Most science apps most tend to be memory bandwidth intensive, and gain from larger cache. Thus, despite the grandiose claims of Intel, hyperthreading is a problem here. In fact, the actual throughput (i.e. in condor sense) of total Mops with & without hyperthreading is often lower with hyperthreading on ... the need to schedule to the processes on the same core often causes bottlenecks that slow down the processing. Thus we often have limited our system to running 1 process per CPU. However, there are times/applications where we would benefit from having hyperthreading enabled, and need to have that as an option, without rebooting the whole cluster. I.e. "full load" in the load average reporting sense is in reality dependent on the application, not on whether the OS reports 1 or 2 processors. Thus it would be quite useful to make this configurable in just a small way. In addition the ganglia web frontend reports the cluster as having 2N Xeon 3.0 GHz physical CPUs, which is twice as many physical CPUs as we really have. This is plainly wrong, with or without the arguments about hyperthreading + load average. My argument is as follows: for most OS's on P4/Xeon, it is fairly easy to determine if HT is enabled. Thus one could report that in gmond as a capability of the processor, and add a configuration value to the appropriate config file to treat a CPU+HT as 1 or two processors, whether in gmetad or the web frontend. For those OS's that don't have that capability, you ignore the option. This is what the OSC patch did for 2.5.x, and it seems like a very useful and easy option to include. So I take it that there is no such option (my original question), since the entire discussion has been about whether I really should want this or not, and not whether it is possible! :-> cheers, rob On Feb 16, 2005, at 8:42 AM, Sean Dilda wrote: Robert E. Parrott wrote: Is there a way to make ganglia hyperthread - aware in v3.0? We have a cluster of dual Xeons with hyperthreading, which ganglia reports as 4 processes. This is annoying when using the web frontend, since full load appears to only be 1/2 load, and people think there are twice as many CPUs available. I'm a little confused as to why you want this. If you have dual processors with HT enabled, then a full load is four processes running, which would give you a load average of 4.0. And since ganglia will indicate that a load of 4.0 is 'full load', then it currently does the right thing. So I guess my question is, how is 4 processes running on a dual proc machine with HT not full load? And if you want full load to be 2 processes running, why are you using HT? --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click ___ Ganglia-general mailing list Ganglia-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ganglia-general
Re: [Ganglia-general] hyperthreading
Robert E. Parrott wrote: Maybe I'm missing something here but full load is NOT 4 processes with hyperthreading. Hyperthreading is a mixed bag, and while great for Desktop use, for compute & memory bandwidth intensive jobs, can be a real drain, because both processes are computing for the same cache. Most science apps most tend to be memory bandwidth intensive, and gain from larger cache. Thus, despite the grandiose claims of Intel, hyperthreading is a problem here. I agree completely. Which is why I assumed that by leaving HT on you decided it was the best option for your cluster and actually wanted jobs to use the virtual processors. In fact, the actual throughput (i.e. in condor sense) of total Mops with & without hyperthreading is often lower with hyperthreading on ... the need to schedule to the processes on the same core often causes bottlenecks that slow down the processing. Thus we often have limited our system to running 1 process per CPU. However, there are times/applications where we would benefit from having hyperthreading enabled, and need to have that as an option, without rebooting the whole cluster. I.e. "full load" in the load average reporting sense is in reality dependent on the application, not on whether the OS reports 1 or 2 processors. Thus it would be quite useful to make this configurable in just a small way. Now I see. That is a tricky setup. In my case, we disabled HT in the entire cluster due to the reasons stated above, as well as the fact that there's only one fpu per physical processor. So I take it that there is no such option (my original question), since the entire discussion has been about whether I really should want this or not, and not whether it is possible! :-> Unfortunately, I don't know of an option that'll do that. I'm sorry if my question bothered you. I was just trying to figure out why you thought ganglia was doing the wrong thing, when I thought it was doing the right thing. I think I understand now.
Re: [Ganglia-general] hyperthreading
No worries ... it's a good and needed dialogue, and (in my opinion) points out the need for flexibility in reporting in ganglia. I'm just trying to convince my boss we really don't HAVE that many CPUs! Seeing is believing, I guess. :-> rob On Feb 16, 2005, at 9:35 AM, Sean Dilda wrote: Robert E. Parrott wrote: Maybe I'm missing something here but full load is NOT 4 processes with hyperthreading. Hyperthreading is a mixed bag, and while great for Desktop use, for compute & memory bandwidth intensive jobs, can be a real drain, because both processes are computing for the same cache. Most science apps most tend to be memory bandwidth intensive, and gain from larger cache. Thus, despite the grandiose claims of Intel, hyperthreading is a problem here. I agree completely. Which is why I assumed that by leaving HT on you decided it was the best option for your cluster and actually wanted jobs to use the virtual processors. In fact, the actual throughput (i.e. in condor sense) of total Mops with & without hyperthreading is often lower with hyperthreading on ... the need to schedule to the processes on the same core often causes bottlenecks that slow down the processing. Thus we often have limited our system to running 1 process per CPU. However, there are times/applications where we would benefit from having hyperthreading enabled, and need to have that as an option, without rebooting the whole cluster. I.e. "full load" in the load average reporting sense is in reality dependent on the application, not on whether the OS reports 1 or 2 processors. Thus it would be quite useful to make this configurable in just a small way. Now I see. That is a tricky setup. In my case, we disabled HT in the entire cluster due to the reasons stated above, as well as the fact that there's only one fpu per physical processor. So I take it that there is no such option (my original question), since the entire discussion has been about whether I really should want this or not, and not whether it is possible! :-> Unfortunately, I don't know of an option that'll do that. I'm sorry if my question bothered you. I was just trying to figure out why you thought ganglia was doing the wrong thing, when I thought it was doing the right thing. I think I understand now.
Re: [Ganglia-general] hyperthreading
please submit this problem to the bugzilla database at http://bugzilla.ganglia.info/ and we'll try to address it in the next release if possible. this has been an issue in the past with people and it's something we should address (at least via some configuration option). if you want an immediate work around, you can modify the ganglia code very easily. if you look in the file ./srclib/libmetrics/linux/metrics.c at line 366 you'll see the code for collecting the number of CPUs (cpu_num_func). you can easily modify the return value to be whatever you want. i know it's not pretty but at least it's immediate. :) -matt Robert E. Parrott wrote: No worries ... it's a good and needed dialogue, and (in my opinion) points out the need for flexibility in reporting in ganglia. I'm just trying to convince my boss we really don't HAVE that many CPUs! Seeing is believing, I guess. :-> rob On Feb 16, 2005, at 9:35 AM, Sean Dilda wrote: Robert E. Parrott wrote: Maybe I'm missing something here but full load is NOT 4 processes with hyperthreading. Hyperthreading is a mixed bag, and while great for Desktop use, for compute & memory bandwidth intensive jobs, can be a real drain, because both processes are computing for the same cache. Most science apps most tend to be memory bandwidth intensive, and gain from larger cache. Thus, despite the grandiose claims of Intel, hyperthreading is a problem here. I agree completely. Which is why I assumed that by leaving HT on you decided it was the best option for your cluster and actually wanted jobs to use the virtual processors. In fact, the actual throughput (i.e. in condor sense) of total Mops with & without hyperthreading is often lower with hyperthreading on ... the need to schedule to the processes on the same core often causes bottlenecks that slow down the processing. Thus we often have limited our system to running 1 process per CPU. However, there are times/applications where we would benefit from having hyperthreading enabled, and need to have that as an option, without rebooting the whole cluster. I.e. "full load" in the load average reporting sense is in reality dependent on the application, not on whether the OS reports 1 or 2 processors. Thus it would be quite useful to make this configurable in just a small way. Now I see. That is a tricky setup. In my case, we disabled HT in the entire cluster due to the reasons stated above, as well as the fact that there's only one fpu per physical processor. So I take it that there is no such option (my original question), since the entire discussion has been about whether I really should want this or not, and not whether it is possible! :-> Unfortunately, I don't know of an option that'll do that. I'm sorry if my question bothered you. I was just trying to figure out why you thought ganglia was doing the wrong thing, when I thought it was doing the right thing. I think I understand now. --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click ___ Ganglia-general mailing list Ganglia-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ganglia-general -- PGP fingerprint 'A7C2 3C2F 8445 AD3C 135E F40B 242A 5984 ACBC 91D3' They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety. --Benjamin Franklin, Historical Review of Pennsylvania, 1759 signature.asc Description: OpenPGP digital signature
Re: [Ganglia-general] hyperthreading
I assume you want HT... If you don't want HT you can 1) change a setting in most bioses, or 2) use the noht option at bot, or 3) compile a kernel without HT support. eric Robert E. Parrott wrote: Is there a way to make ganglia hyperthread - aware in v3.0? We have a cluster of dual Xeons with hyperthreading, which ganglia reports as 4 processes. This is annoying when using the web frontend, since full load appears to only be 1/2 load, and people think there are twice as many CPUs available. With 2.5.7, I hacked the code using a patch from OSC to only report 2 processor per real processor when hyperthreading was found enabled. However, in 3.0 this is not enabled, so I've backed down to 2.5.7 again. Is there a reason this kind of patch is not in place? Are there options I;m not aware of in the config files? thanx, rob --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click ___ Ganglia-general mailing list Ganglia-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ganglia-general
Re: [Ganglia-general] Hyperthreading and cpu_num
Hi Hugo: On Tue, Oct 12, 2010 at 1:21 PM, Hernandez, Hugo (NIH/NIAID) [C] wrote: > I have some XEON 5560 compute nodes which have enabled hyperthreading. At > this point, the OS (RHEL 5.4) is reporting 16 ‘cores’ but we already have 8 > per compute node. There is a way to force ganglia to report the number of > real CPUs instead of the number of ‘virtual+real’ CPUs? Any help will be > greatly appreciated. Here's the Bugzilla entry which describes the issue you're encountering: http://bugzilla.ganglia.info/cgi-bin/bugzilla/show_bug.cgi?id=84 And here's a possible workaround: http://forums.ganglia.info/viewtopic.php?f=4&t=8&sid=0417f3deeb9d6b1af72e92285fdd2017 We should try to work out a solution though... any takers? Cheers, Bernard -- Download new Adobe(R) Flash(R) Builder(TM) 4 The new Adobe(R) Flex(R) 4 and Flash(R) Builder(TM) 4 (formerly Flex(R) Builder(TM)) enable the development of rich applications that run across multiple browsers and platforms. Download your free trials today! http://p.sf.net/sfu/adobe-dev2dev ___ Ganglia-general mailing list Ganglia-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ganglia-general
Re: [Ganglia-general] Hyperthreading and cpu_num
Here it was my solution:
# get the correct number of real CPUs (two quad-core processors)
CPU_NUM=`cat /proc/cpuinfo | grep cores | uniq | awk '{ print $4*2 }'`
# Retrieve the number of real CPUs on Ganglia
/opt/ganglia/bin/gmetric -t uint32 -s zero -n 'cpu_num' -v $CPU_NUM -u
'CPUs'
Thanks a lot!
-Hugo
On 10/14/10 6:22 PM, "Bernard Li" wrote:
> Hi Hugo:
>
> On Tue, Oct 12, 2010 at 1:21 PM, Hernandez, Hugo (NIH/NIAID) [C]
> wrote:
>
>> I have some XEON 5560 compute nodes which have enabled hyperthreading. At
>> this point, the OS (RHEL 5.4) is reporting 16 Œcores¹ but we already have 8
>> per compute node. There is a way to force ganglia to report the number of
>> real CPUs instead of the number of Œvirtual+real¹ CPUs? Any help will be
>> greatly appreciated.
>
> Here's the Bugzilla entry which describes the issue you're encountering:
>
> http://bugzilla.ganglia.info/cgi-bin/bugzilla/show_bug.cgi?id=84
>
> And here's a possible workaround:
>
> http://forums.ganglia.info/viewtopic.php?f=4&t=8&sid=0417f3deeb9d6b1af72e92285
> fdd2017
>
> We should try to work out a solution though... any takers?
>
> Cheers,
>
> Bernard
--
Hugo R. Hernandez
--
"Si seus esforços, foram vistos com indefrença, não desanime, que o sol faze
un espectacolo maravilhoso todas as manhãs cuando a maior parte das pessoas,
ainda estam durmindo"
- Anónimo brasileiro
Disclaimer: The information in this e-mail and any of its attachments is
confidential and may contain sensitive information. It should not be used by
anyone who is not the original intended recipient. If you have received this
e-mail in error please inform the sender and delete it from your mailbox or
any other storage devices. National Institute of Allergy and Infectious
Diseases shall not accept liability for any statements made that are
sender's own and not expressly made on behalf of the NIAID by one of its
representatives.
--
Download new Adobe(R) Flash(R) Builder(TM) 4
The new Adobe(R) Flex(R) 4 and Flash(R) Builder(TM) 4 (formerly
Flex(R) Builder(TM)) enable the development of rich applications that run
across multiple browsers and platforms. Download your free trials today!
http://p.sf.net/sfu/adobe-dev2dev
___
Ganglia-general mailing list
Ganglia-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ganglia-general
Re: [Ganglia-general] Hyperthreading and cpu_num
On Mon, Oct 18, 2010 at 15:39, Hernandez, Hugo (NIH/NIAID) [C]
wrote:
> Here it was my solution:
>
> # get the correct number of real CPUs (two quad-core processors)
> CPU_NUM=`cat /proc/cpuinfo | grep cores | uniq | awk '{ print $4*2 }'`
Here's a slightly more efficient version to compute the same thing:
CPU_NUM=`awk '/cores/{print $4 * 2; exit}' /proc/cpuinfo`
However, I'm not sure that will be accurate in all cases.
Try this instead?
CPU_NUM=`awk '/^phys/' /proc/cpuinfo |sort -u | wc -l
Or even:
CPU_NUM=`awk '/^phys/{CPU[$4]++} END {print length(CPU)}' /proc/cpuinfo`
--
Jesse Becker
--
Download new Adobe(R) Flash(R) Builder(TM) 4
The new Adobe(R) Flex(R) 4 and Flash(R) Builder(TM) 4 (formerly
Flex(R) Builder(TM)) enable the development of rich applications that run
across multiple browsers and platforms. Download your free trials today!
http://p.sf.net/sfu/adobe-dev2dev
___
Ganglia-general mailing list
Ganglia-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ganglia-general
Re: [Ganglia-general] Hyperthreading and cpu_num
Thanks, Jesse. Your suggestions worked as well.
On 10/18/10 3:56 PM, "Jesse Becker" wrote:
> On Mon, Oct 18, 2010 at 15:39, Hernandez, Hugo (NIH/NIAID) [C]
> wrote:
>> Here it was my solution:
>>
>> # get the correct number of real CPUs (two quad-core processors)
>> CPU_NUM=`cat /proc/cpuinfo | grep cores | uniq | awk '{ print $4*2 }'`
>
> Here's a slightly more efficient version to compute the same thing:
>
> CPU_NUM=`awk '/cores/{print $4 * 2; exit}' /proc/cpuinfo`
>
> However, I'm not sure that will be accurate in all cases.
>
> Try this instead?
>
> CPU_NUM=`awk '/^phys/' /proc/cpuinfo |sort -u | wc -l
>
> Or even:
> CPU_NUM=`awk '/^phys/{CPU[$4]++} END {print length(CPU)}' /proc/cpuinfo`
--
Hugo R. Hernandez
Sr. Systems Administrator
Dell | Services Federal Government
National Institutes of Health ‹ NIAID/OCICB/OEB
10401 Fernwood Drive
Fernwood West - Rm. 2009
Bethesda, MD 20817
Phone: 301-841-4203
Cell: 240-479-1888
--
"Si seus esforços, foram vistos com indefrença, não desanime, que o sol faze
un espectacolo maravilhoso todas as manhãs cuando a maior parte das pessoas,
ainda estam durmindo"
- Anónimo brasileiro
Disclaimer: The information in this e-mail and any of its attachments is
confidential and may contain sensitive information. It should not be used by
anyone who is not the original intended recipient. If you have received this
e-mail in error please inform the sender and delete it from your mailbox or
any other storage devices. National Institute of Allergy and Infectious
Diseases shall not accept liability for any statements made that are
sender's own and not expressly made on behalf of the NIAID by one of its
representatives.
--
Nokia and AT&T present the 2010 Calling All Innovators-North America contest
Create new apps & games for the Nokia N8 for consumers in U.S. and Canada
$10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing
Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store
http://p.sf.net/sfu/nokia-dev2dev
___
Ganglia-general mailing list
Ganglia-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ganglia-general
