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
[email protected]
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

Attachment: signature.asc
Description: OpenPGP digital signature

Reply via email to