On Thu, Mar 12, 2009 at 1:57 PM, Jody McIntyre <scjody@xxxxxxx> wrote:
> This patch tracks various statistics related to the performance of a RAID 5
> or 6 array. These have been useful to us in the past to help solve
> performance issues. They are reported via the 'stat' file in each device's
> 'md' sysfs directory, e.g. /sys/class/block/md0/md/stat .
>
> A slight amount of overhead is added by the atomic_inc() and atomic_dec()
> calls used in these patches, but it's so low I've been unable to measure it.
> Both calls are already used extensively in raid5.c to track internal
> counters so I believe this is OK.
>
Hi Jody,
I am curious, can you say a bit more about the performance problems
you solved with this data? Is there a corresponding userspace tool
that interprets these numbers? My earlier recommendation to use some
type of tracepoint had more to do with the fact that the data could be
interpreted by existing tools rather than the overhead. Looking a bit
closer at the statistics it seems most are currently available via
/proc/diskstats and blktrace...
[..]
> +static ssize_t
> +stat_show(mddev_t *mddev, char *page)
> +{
> + raid5_conf_t *conf = mddev_to_conf(mddev);
> + if (conf)
> + return sprintf(page, "%u %u %u %u %u %u %u %u %u %u %u %u %u\n",
> + atomic_read(&conf->reads_in),
> + atomic_read(&conf->writes_in),
> + atomic_read(&conf->reads_out),
> + atomic_read(&conf->writes_out),
...available in /proc/diskstats and blktrace.
> + atomic_read(&conf->reads_for_rmw),
> + atomic_read(&conf->reads_for_rcw),
> + atomic_read(&conf->aligned_reads),
...these could be useful as there is no other way to retrieve this information.
> + atomic_read(&conf->active_stripes),
...duplicate of stripe_cache_active attribute
> + atomic_read(&conf->in_reqs_in_queue),
> + atomic_read(&conf->out_reqs_in_queue),
...available via blktrace
> + atomic_read(&conf->delayed),
> + atomic_read(&conf->bit_delayed),
> + atomic_read(&conf->out_of_stripes));
...these could be useful
So, my original suggestion/question should have been why not extend
blktrace to understand these incremental MD events?
Regards,
Dan
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
