>>> On 7/16/2007 at 7:54 PM, in message
<[EMAIL PROTECTED]>, "Bernard Li"
<[EMAIL PROTECTED]> wrote:
> Hi Brad:
> 
> On 7/16/07, Brad Nicholes <[EMAIL PROTECTED]> wrote:
> 
>> Slurpfile is probably doing the right thing by reporting that the file 
> doesn't exist when it goes to read it (however it should probably state which 
> file it can't read).  In this case metric_init() should probably stat() the 
> file before it calls slurpfile() and then assign the default value if stat() 
> fails.
> 
> Okay slurpfile now reports the filename that gave the error:
> 
> http://ganglia.svn.sourceforge.net/viewvc/ganglia?view=rev&revision=816 
> 
> However, I noticed that in metrics.c, some invocation of slurpfile in
> metric_init() also returns the filename, but some don't -- seems to be
> all over the place currently.
> 
> And the fix for libmetrics/linux/metrics.c is inline:
> 
> Index: libmetrics/linux/metrics.c
> ===================================================================
> --- libmetrics/linux/metrics.c  (revision 814)
> +++ libmetrics/linux/metrics.c  (working copy)
> @@ -164,13 +164,25 @@
>  {
>     g_val_t rval;
>     char * dummy;
> +   struct stat struct_stat;
> 
>     num_cpustates = num_cpustates_func();
> 
> -   cpufreq = 1;
> -   rval.int32 =
> slurpfile("/sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq",
> sys_devices_system_cpu, BUFFSIZE);
> -   if ( rval.int32 == SYNAPSE_FAILURE )
> -      cpufreq = 0;
> +   /* /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq is only
> available on newer kernels, so stat to make sure it exists */
> +   /* before slurping the file */
> +   cpufreq = 0;
> +   if ( ! (stat("/sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq",
> &struct_stat)) )
> +      {
> +         rval.int32 =
> slurpfile("/sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq",
> sys_devices_system_cpu, BUFFSIZE);
> +         if ( rval.int32 == SYNAPSE_FAILURE )
> +            {
> +               err_msg("metric_init() got an error from slurpfile()");
> +            }
> +         else
> +            {
> +               cpufreq = 1;
> +            }
> +      }
> 
>     rval.int32 = slurpfile("/proc/cpuinfo", proc_cpuinfo, BUFFSIZE);
>     if ( rval.int32 == SYNAPSE_FAILURE )
> 
> Any volunteers with a newer kernel can test this before I apply?
> 

I don't think that it should write out another error message.  Slurpfile will 
be writing out a message already stating that the file can't be found.  One of 
the purposes for reading this file is to simply determine if cpu_speed needs to 
be  adjusted in the function cpu_speed_func().  If the file doesn't exist, it 
isn't really an error, it just means that cpu_speed doesn't need to be 
adjusted, so writing out an error message would probably be confusing to the 
user.  Also, and somebody can correct me if I am wrong, I am not sure that this 
file depends on a newer kernel.  I think that it depends on whether the 
hardware supports this functionality or not as to whether the file actually 
exists.

BTW, the note attached to the patch in SVN 
(http://ganglia.svn.sourceforge.net/viewvc/ganglia/trunk/monitor-core/libmetrics/linux/metrics.c?revision=741&view=markup)
 states that one of the purposes of adjusting the cpu_speed is to compensate 
for the fact that each CPU can't be tracked independently.  Tracking each CPU 
independently now exists in Ganglia 3.1.x in the gmond/modules/multicpu.c 
module.  The built-in cpu_speed_func() would still need to have to make this 
adjustment, but if the user would rather report each cpu speed rather than an 
adjusted average, that can now be done.

Brad

Brad


-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Ganglia-developers mailing list
Ganglia-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ganglia-developers

Reply via email to