Hi, 2011/2/19 explore_zjx <explore_...@126.com>: > Hi, everyone: > I wanna to ask a question about libpfm4. In the perf_example > directory, there are some examples about the use of libpfm4. In the source > code, the value must be scaled after the valued was read. It completed > scaling by calling the function :perf_scale(). However, I can't understand > why the readed PMU data should scaling.
In perf_events, the kernel multiplexes events when the PMU is overcommitted, i.e., when there are more events than counters to measure them. Furthermore, PMU is shared between all users. Thus, even if you are measuring a single event, you cannot predict whether or not you will be multiplexed. With multiplexing the event is not measuring 100% of the time. Thus, through scaling you get get an estimate of the number of events. To scale you need to request that the kernel tracks time_enabled (time between start and stop) and time_running (time the event was actually on the PMU). > And the returned Value, what's the mean of Value[0]. How can I get some > documention about the read data format? Would you like to response me? Value[0] is the unscaled count, i.e., accumulated number of occurrences of the event during the time it was actually measuring on the PMU. The read format is documented in /usr/include/perf_event.h in the comments. > On the other hand, I want to consult everyone a question about > programming. In the application, there are two threads, one is main thread, > the other is slice thread. I want to control some parameters in the slice > thread by sampling the PMU events. When some condition is satisfied, then > the slice thread must change its parameters. Some paper suggests piggyback > the slice thread, but I can't understand it. How about your suggestion? > Looking forward to hear from you! > Best regards! > Jason > 2011/2/19 > > > > At 2011-02-18 02:19:48，perfmon2-devel-requ...@lists.sourceforge.net wrote: > >>Send perfmon2-devel mailing list submissions to >> perfmon2-devel@lists.sourceforge.net >> >>To subscribe or unsubscribe via the World Wide Web, visit >> https://lists.sourceforge.net/lists/listinfo/perfmon2-devel >>or, via email, send a message with subject or body 'help' to >> perfmon2-devel-requ...@lists.sourceforge.net >> >>You can reach the person managing the list at >> perfmon2-devel-ow...@lists.sourceforge.net >> >>When replying, please edit your Subject line so it is more specific >>than "Re: Contents of perfmon2-devel digest..." >> >> >>Today's Topics: >> >> 1. Re: [PATCH] Handle API changes for python (Arun Sharma) >> 2. Re: [PATCH] Handle API changes for python (stephane eranian) >> 3. [PATCH] perf: make perf stat print user provided full event >> names (Stephane Eranian) >> 4. Re: [BUG] perf: perf report -n shows bogus number of samples >> (Arnaldo Carvalho de Melo) >> 5. Re: [BUG] perf: perf report -n shows bogus number of samples >> (Stephane Eranian) >> >> >>---------------------------------------------------------------------- >> >>Message: 1 >>Date: Tue, 15 Feb 2011 15:04:49 -0800 >>From: Arun Sharma <asha...@fb.com> >>Subject: Re: [perfmon2] [PATCH] Handle API changes for python >>To: Stephane Eranian <eran...@google.com> >>Cc: perfmon2-devel@lists.sourceforge.net >>Message-ID: <20110215230449.ga22...@radium.snc4.facebook.com> >>Content-Type: text/plain; charset=us-ascii >> >>On Tue, Feb 15, 2011 at 11:48:17PM +0100, Stephane Eranian wrote: >>> >>> Why do you need to remove #if 0 code? >> >>I don't need to. Feel free to ignore that part of the patch :) >> >> -Arun >> >> >> >>------------------------------ >> >>Message: 2 >>Date: Wed, 16 Feb 2011 10:18:13 +0100 >>From: stephane eranian <eran...@googlemail.com> >>Subject: Re: [perfmon2] [PATCH] Handle API changes for python >>To: Arun Sharma <asha...@fb.com> >>Cc: perfmon2-devel@lists.sourceforge.net, Stephane Eranian >> <eran...@google.com> >>Message-ID: >> <AANLkTim0J=f7usyucxprwckobg4nydsvcc_d18jwf...@mail.gmail.com> >>Content-Type: text/plain; charset=UTF-8 >> >>Patch applied. >>Thanks. >> >>On Wed, Feb 16, 2011 at 12:04 AM, Arun Sharma <asha...@fb.com> wrote: >>> On Tue, Feb 15, 2011 at 11:48:17PM +0100, Stephane Eranian wrote: >>>> >>>> Why do you need to remove #if 0 code? >>> >>> I don't need to. Feel free to ignore that part of the patch :) >>> >>> ?-Arun >>> >>> ------------------------------------------------------------------------------ >>> The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: >>> Pinpoint memory and threading errors before they happen. >>> Find and fix more than 250 security defects in the development cycle. >>> Locate bottlenecks in serial and parallel code that limit performance. >>> http://p.sf.net/sfu/intel-dev2devfeb >>> _______________________________________________ >>> perfmon2-devel mailing list >>> perfmon2-devel@lists.sourceforge.net >>> https://lists.sourceforge.net/lists/listinfo/perfmon2-devel >>> >> >> >> >>------------------------------ >> >>Message: 3 >>Date: Wed, 16 Feb 2011 15:10:01 +0200 >>From: Stephane Eranian <eran...@google.com> >>Subject: [perfmon2] [PATCH] perf: make perf stat print user provided >> full event names >>To: linux-ker...@vger.kernel.org >>Cc: perfmon2-de...@lists.sf.net, linux-perf-us...@vger.kernel.org, >> eran...@gmail.com, pet...@infradead.org, fweis...@gmail.com, >> eran...@google.com, a...@redhat.com, pau...@samba.org, mi...@elte.hu, >> da...@davemloft.net >>Message-ID: <4d5bdc64.98a1df0a.7aa3.0...@mx.google.com> >> >>This patch changes the way perf stat prints event names at the end >>of a run. Until now, it was trying to reconstruct the event name >>from its encoding. The problem is that it would only print generic >>events without their modifiers (u, k, pp). >> >>This patch saves the event name as passed by the user in the evsel >>struct and uses it to print the final event name. >> >>This would also work in case perf is linked with a library (such as >>libpfm4) which provides full PMU event tables. >> >>$ perf stat -e cycles:u,cycles:k date >>Wed Feb 16 14:58:52 CET 2011 >> >> Performance counter stats for 'date': >> >> 568600 cycles:u >> 2779715 cycles:k >> >> 0.001908182 seconds time elapsed >> >>Signed-off-by: Stephane Eranian <eran...@google.com> >>--- >> >>diff --git a/tools/perf/util/evsel.c b/tools/perf/util/evsel.c >>index 211063e..5f1f364 100644 >>--- a/tools/perf/util/evsel.c >>+++ b/tools/perf/util/evsel.c >>@@ -85,6 +85,7 @@ void perf_evsel__exit(struct perf_evsel *evsel) >> void perf_evsel__delete(struct perf_evsel *evsel) >> { >> perf_evsel__exit(evsel); >>+ free(evsel->name); >> free(evsel); >> } >> >>diff --git a/tools/perf/util/evsel.h b/tools/perf/util/evsel.h >>index eecdc3a..c32b348 100644 >>--- a/tools/perf/util/evsel.h >>+++ b/tools/perf/util/evsel.h >>@@ -45,6 +45,7 @@ struct perf_evsel { >> struct perf_counts *counts; >> int idx; >> void *priv; >>+ char *name; >> }; >> >> struct cpu_map; >>diff --git a/tools/perf/util/parse-events.c b/tools/perf/util/parse-events.c >>index cf082da..80a3dd5 100644 >>--- a/tools/perf/util/parse-events.c >>+++ b/tools/perf/util/parse-events.c >>@@ -268,6 +268,9 @@ const char *event_name(struct perf_evsel *evsel) >> u64 config = evsel->attr.config; >> int type = evsel->attr.type; >> >>+ if (evsel->name) >>+ return evsel->name; >>+ >> return __event_name(type, config); >> } >> >>@@ -782,8 +785,10 @@ int parse_events(const struct option *opt, const char *str, int unset __used) >> struct perf_evlist *evlist = *(struct perf_evlist **)opt->value; >> struct perf_event_attr attr; >> enum event_result ret; >>+ const char *ostr; >> >> for (;;) { >>+ ostr = str; >> memset(&attr, 0, sizeof(attr)); >> ret = parse_event_symbols(opt, &str, &attr); >> if (ret == EVT_FAILED) >>@@ -798,6 +803,11 @@ int parse_events(const struct option *opt, const char *str, int unset __used) >> if (evsel == NULL) >> return -1; >> perf_evlist__add(evlist, evsel); >>+ >>+ evsel->name = calloc(str - ostr + 1, 1); >>+ if (!evsel->name) >>+ return -1; >>+ strncpy(evsel->name, ostr, str - ostr); >> } >> >> if (*str == 0) >> >> >> >>------------------------------ >> >>Message: 4 >>Date: Thu, 17 Feb 2011 13:23:13 -0200 >>From: Arnaldo Carvalho de Melo <a...@redhat.com> >>Subject: Re: [perfmon2] [BUG] perf: perf report -n shows bogus number >> of samples >>To: Stephane Eranian <eran...@google.com> >>Cc: Peter Zijlstra <pet...@infradead.org>, Fr?d?ric Weisbecker >> <fweis...@gmail.com>, mi...@elte.hu, LKML >> <linux-ker...@vger.kernel.org>, perfmon2-de...@lists.sf.net >>Message-ID: <20110217152313.gd10...@ghostprotocols.net> >>Content-Type: text/plain; charset=us-ascii >> >>Em Wed, Feb 09, 2011 at 12:34:44AM +0100, Stephane Eranian escreveu: >>> I think the -n option of perf report shows bogus number of samples. >>> >>> I believe it does not print the number of samples but rather the >>> number of events if I understand the code in hist_entry__snprintf(). >>> I think that's useless, the number of samples is more useful. >> >><SNIP >> >>> $ perf record -e cycles ./repmov >>> $ perf report -D | fgrep RECORD_SAMPLE | wc -l >>> 86346 >>> $ ./perf report -n >>> # Events: 86K cycles >>> # >>> # Overhead Samples Command Shared Object Symbol >>> # ........ .......... ....... ................. ......................... >>> # >>> 98.92%238206388334 repmov repmov [.] main >>> 0.08% 189506224 repmov [kernel.kallsyms] [k] perf_ctx_adjust_freq >>> 0.06% 147582706 repmov [kernel.kallsyms] [k] perf_event_task_tick >>> >>> It should be easy to reproduce with any other program. >> >>Like this? Can I have your acked-by? >> >>commit 58e57f4dd6164bdbd5bc1f7d7c1ba5eb104e9b32 >>Author: Arnaldo Carvalho de Melo <a...@redhat.com> >>Date: Thu Feb 17 10:37:23 2011 -0200 >> >> perf hists: Print number of samples, not the period sum >> >> So that we match the header where we state the number of events with the >> "Samples" column when using 'perf report -n/--show-nr-samples': >> >> [root@emilia ~]# perf record -a sleep 1 >> [ perf record: Woken up 1 times to write data ] >> [ perf record: Captured and wrote 0.111 MB perf.data (~4860 samples) ] >> [root@emilia ~]# perf report --stdio --show-nr-samples >> # Events: 11 cycles >> # >> # Overhead Samples Command Shared Object Symbol >> # ........ .......... ........... .................. ............................ >> # >> 16.65% 1 sleep [kernel.kallsyms] [k] unmap_vmas >> 16.10% 1 perf libpthread-2.12.so [.] __pthread_cleanup_push_defer >> 15.79% 2 perf [kernel.kallsyms] [k] format_decode >> 12.88% 1 kworker/1:2 [kernel.kallsyms] [k] cache_reap >> 10.69% 1 swapper [kernel.kallsyms] [k] _raw_spin_lock >> 7.55% 1 sleep [kernel.kallsyms] [k] prepare_exec_creds >> 6.00% 1 perf [jbd2] [k] start_this_handle >> 5.29% 1 perf [kernel.kallsyms] [k] seq_read >> 4.75% 1 perf [kernel.kallsyms] [k] get_pid_task >> 4.30% 1 perf [kernel.kallsyms] [k] _raw_spin_unlock_irqrestore >> >> # >> # (For a higher level overview, try: perf report --sort comm,dso) >> # >> [root@emilia ~]# >> >> Reported-by: Stephane Eranian <eran...@google.com> >> Cc: Frederic Weisbecker <fweis...@gmail.com> >> Cc: Ingo Molnar <mi...@elte.hu> >> Cc: Mike Galbraith <efa...@gmx.de> >> Cc: Paul Mackerras <pau...@samba.org> >> Cc: Peter Zijlstra <pet...@infradead.org> >> Cc: Stephane Eranian <eran...@google.com> >> Cc: Tom Zanussi <tzanu...@gmail.com> >> LKML-Reference: <new-submission> >> Signed-off-by: Arnaldo Carvalho de Melo <a...@redhat.com> >> >>diff --git a/tools/perf/util/hist.c b/tools/perf/util/hist.c >>index 3f43723..da2899e 100644 >>--- a/tools/perf/util/hist.c >>+++ b/tools/perf/util/hist.c >>@@ -591,6 +591,7 @@ int hist_entry__snprintf(struct hist_entry *self, char *s, size_t size, >> { >> struct sort_entry *se; >> >>u64 period, total, period_sys, period_us, period_guest_sys, period_guest_us; >>+ u64 nr_events; >> const char *sep = symbol_conf.field_sep; >> int ret; >> >>@@ -599,6 +600,7 @@ int hist_entry__snprintf(struct hist_entry *self, char *s, size_t size, >> >> if (pair_hists) { >> period = self->pair ? self->pair->period : 0; >>+ nr_events = self->pair ? self->pair->nr_events : 0; >> total = pair_hists->stats.total_period; >> period_sys = self->pair ? self->pair->period_sys : 0; >> period_us = self->pair ? self->pair->period_us : 0; >>@@ -606,6 +608,7 @@ int hist_entry__snprintf(struct hist_entry *self, char *s, size_t size, >> period_guest_us = self->pair ? self->pair->period_guest_us : 0; >> } else { >> period = self->period; >>+ nr_events = self->nr_events; >> total = session_total; >> period_sys = self->period_sys; >> period_us = self->period_us; >>@@ -646,9 +649,9 @@ int hist_entry__snprintf(struct hist_entry *self, char *s, size_t size, >> >> if (symbol_conf.show_nr_samples) { >> if (sep) >>- >>ret += snprintf(s + ret, size - ret, "%c%" PRIu64, *sep, period); >>+ >>ret += snprintf(s + ret, size - ret, "%c%" PRIu64, *sep, nr_events); >> else >>- >>ret += snprintf(s + ret, size - ret, "%11" PRIu64, period); >>+ >>ret += snprintf(s + ret, size - ret, "%11" PRIu64, nr_events); >> } >> >> if (pair_hists) { >> >> >> >>------------------------------ >> >>Message: 5 >>Date: Thu, 17 Feb 2011 19:19:37 +0100 >>From: Stephane Eranian <eran...@google.com> >>Subject: Re: [perfmon2] [BUG] perf: perf report -n shows bogus number >> of samples >>To: Arnaldo Carvalho de Melo <a...@redhat.com> >>Cc: Peter Zijlstra <pet...@infradead.org>, Fr?d?ric Weisbecker >> <fweis...@gmail.com>, mi...@elte.hu, LKML >> <linux-ker...@vger.kernel.org>, perfmon2-de...@lists.sf.net >>Message-ID: >> <AANLkTi=cbx7pdwpnl4qr1+ga37bq63x5cs_bw70ya...@mail.gmail.com> >>Content-Type: text/plain; charset=UTF-8 >> >>On Thu, Feb 17, 2011 at 4:23 PM, Arnaldo Carvalho de Melo >><a...@redhat.com> wrote: >>> Em Wed, Feb 09, 2011 at 12:34:44AM +0100, Stephane Eranian escreveu: >>>> I think the -n option of perf report shows bogus number of samples. >>>> >>>> I believe it does not print the number of samples but rather the >>>> number of events if I understand the code in hist_entry__snprintf(). >>>> I think that's useless, the number of samples is more useful. >>> >>> <SNIP >>> >>>> $ perf record -e cycles ./repmov >>>> $ perf report -D | fgrep RECORD_SAMPLE | wc -l >>>> 86346 >>>> $ ./perf report -n >>>> # Events: 86K cycles >>>> # >>>> # Overhead ?Samples ? ?Command ? ? ?Shared Object ? ? ? ? ? ? ? ? ? ? Symbol >>>> # ........ .......... ?....... ?................. ?......................... >>>> # >>>> ? ? 98.92%238206388334 ? repmov ?repmov ? ? ? ? ? ? [.] main >>>> ? ? ?0.08% ?189506224 ? repmov ?[kernel.kallsyms] ?[k] perf_ctx_adjust_freq >>>> ? ? ?0.06% ?147582706 ? repmov ?[kernel.kallsyms] ?[k] perf_event_task_tick >>>> >>>> It should be easy to reproduce with any other program. >>> >>> Like this? Can I have your acked-by? >>> >>Yes. Works for me. >> >>Acked-by: Stephane Eranian <eran...@google.com> >> >>> commit 58e57f4dd6164bdbd5bc1f7d7c1ba5eb104e9b32 >>> Author: Arnaldo Carvalho de Melo <a...@redhat.com> >>> Date: ? Thu Feb 17 10:37:23 2011 -0200 >>> >>> ? ?perf hists: Print number of samples, not the period sum >>> >>> ? ?So that we match the header where we state the number of events with the >>> ? ?"Samples" column when using 'perf report -n/--show-nr-samples': >>> >>> ? ? [root@emilia ~]# perf record -a sleep 1 >>> ? ? [ perf record: Woken up 1 times to write data ] >>> ? ? [ perf record: Captured and wrote 0.111 MB perf.data (~4860 samples) ] >>> ? ? [root@emilia ~]# perf report --stdio --show-nr-samples >>> ? ? # Events: 11 ?cycles >>> ? ? # >>> ? ? # Overhead ?Samples ? ? ? ?Command ? ? ? Shared Object ? ? ? ? ? ? ? ? ? ? ? ?Symbol >>> ? ? # ........ .......... ?........... ?.................. ?............................ >>> ? ? # >>> ? ? ? ? 16.65% ? ? ? ? ?1 ? ? ? ?sleep ?[kernel.kallsyms] ? [k] unmap_vmas >>> ? ? ? ? 16.10% ? ? ? ? ?1 ? ? ? ? perf ?libpthread-2.12.so ?[.] __pthread_cleanup_push_defer >>> ? ? ? ? 15.79% ? ? ? ? ?2 ? ? ? ? perf ?[kernel.kallsyms] ? [k] format_decode >>> ? ? ? ? 12.88% ? ? ? ? ?1 ?kworker/1:2 ?[kernel.kallsyms] ? [k] cache_reap >>> ? ? ? ? 10.69% ? ? ? ? ?1 ? ? ?swapper ?[kernel.kallsyms] ? [k] _raw_spin_lock >>> ? ? ? ? ?7.55% ? ? ? ? ?1 ? ? ? ?sleep ?[kernel.kallsyms] ? [k] prepare_exec_creds >>> ? ? ? ? ?6.00% ? ? ? ? ?1 ? ? ? ? perf ?[jbd2] ? ? ? ? ? ? ?[k] start_this_handle >>> ? ? ? ? ?5.29% ? ? ? ? ?1 ? ? ? ? perf ?[kernel.kallsyms] ? [k] seq_read >>> ? ? ? ? ?4.75% ? ? ? ? ?1 ? ? ? ? perf ?[kernel.kallsyms] ? [k] get_pid_task >>> ? ? ? ? ?4.30% ? ? ? ? ?1 ? ? ? ? perf ?[kernel.kallsyms] ? [k] _raw_spin_unlock_irqrestore >>> >>> ? ? # >>> ? ? # (For a higher level overview, try: perf report --sort comm,dso) >>> ? ? # >>> ? ? [root@emilia ~]# >>> >>> ? ?Reported-by: Stephane Eranian <eran...@google.com> >>> ? ?Cc: Frederic Weisbecker <fweis...@gmail.com> >>> ? ?Cc: Ingo Molnar <mi...@elte.hu> >>> ? ?Cc: Mike Galbraith <efa...@gmx.de> >>> ? ?Cc: Paul Mackerras <pau...@samba.org> >>> ? ?Cc: Peter Zijlstra <pet...@infradead.org> >>> ? ?Cc: Stephane Eranian <eran...@google.com> >>> ? ?Cc: Tom Zanussi <tzanu...@gmail.com> >>> ? ?LKML-Reference: <new-submission> >>> ? ?Signed-off-by: Arnaldo Carvalho de Melo <a...@redhat.com> >>> >>> diff --git a/tools/perf/util/hist.c b/tools/perf/util/hist.c >>> index 3f43723..da2899e 100644 >>> --- a/tools/perf/util/hist.c >>> +++ b/tools/perf/util/hist.c >>> @@ -591,6 +591,7 @@ int hist_entry__snprintf(struct hist_entry *self, char *s, size_t size, >>> ?{ >>> ? ? ? ?struct sort_entry *se; >>> ? ? ? ?u64 period, total, period_sys, period_us, period_guest_sys, period_guest_us; >>> + ? ? ? u64 nr_events; >>> ? ? ? ?const char *sep = symbol_conf.field_sep; >>> ? ? ? ?int ret; >>> >>> @@ -599,6 +600,7 @@ int hist_entry__snprintf(struct hist_entry *self, char *s, size_t size, >>> >>> ? ? ? ?if (pair_hists) { >>> ? ? ? ? ? ? ? ?period = self->pair ? self->pair->period : 0; >>> + ? ? ? ? ? ? ? nr_events = self->pair ? self->pair->nr_events : 0; >>> ? ? ? ? ? ? ? ?total = pair_hists->stats.total_period; >>> ? ? ? ? ? ? ? ?period_sys = self->pair ? self->pair->period_sys : 0; >>> ? ? ? ? ? ? ? ?period_us = self->pair ? self->pair->period_us : 0; >>> @@ -606,6 +608,7 @@ int hist_entry__snprintf(struct hist_entry *self, char *s, size_t size, >>> ? ? ? ? ? ? ? ?period_guest_us = self->pair ? self->pair->period_guest_us : 0; >>> ? ? ? ?} else { >>> ? ? ? ? ? ? ? ?period = self->period; >>> + ? ? ? ? ? ? ? nr_events = self->nr_events; >>> ? ? ? ? ? ? ? ?total = session_total; >>> ? ? ? ? ? ? ? ?period_sys = self->period_sys; >>> ? ? ? ? ? ? ? ?period_us = self->period_us; >>> @@ -646,9 +649,9 @@ int hist_entry__snprintf(struct hist_entry *self, char *s, size_t size, >>> >>> ? ? ? ?if (symbol_conf.show_nr_samples) { >>> ? ? ? ? ? ? ? ?if (sep) >>> - ? ? ? ? ? ? ? ? ? ? ? ret += snprintf(s + ret, size - ret, "%c%" PRIu64, *sep, period); >>> + ? ? ? ? ? ? ? ? ? ? ? ret += snprintf(s + ret, size - ret, "%c%" PRIu64, *sep, nr_events); >>> ? ? ? ? ? ? ? ?else >>> - ? ? ? ? ? ? ? ? ? ? ? ret += snprintf(s + ret, size - ret, "%11" PRIu64, period); >>> + ? ? ? ? ? ? ? ? ? ? ? ret += snprintf(s + ret, size - ret, "%11" PRIu64, nr_events); >>> ? ? ? ?} >>> >>> ? ? ? ?if (pair_hists) { >>> >> >> >> >>------------------------------ >> >>------------------------------------------------------------------------------ >>The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: >>Pinpoint memory and threading errors before they happen. >>Find and fix more than 250 security defects in the development cycle. >>Locate bottlenecks in serial and parallel code that limit performance. >>http://p.sf.net/sfu/intel-dev2devfeb >> >>------------------------------ >> >>_______________________________________________ >>perfmon2-devel mailing list >>perfmon2-devel@lists.sourceforge.net >>https://lists.sourceforge.net/lists/listinfo/perfmon2-devel >> >> >>End of perfmon2-devel Digest, Vol 40, Issue 15 >>********************************************** > > > > ------------------------------------------------------------------------------ > The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: > Pinpoint memory and threading errors before they happen. > Find and fix more than 250 security defects in the development cycle. > Locate bottlenecks in serial and parallel code that limit performance. > http://p.sf.net/sfu/intel-dev2devfeb > _______________________________________________ > perfmon2-devel mailing list > perfmon2-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/perfmon2-devel > > ------------------------------------------------------------------------------ Index, Search & Analyze Logs and other IT data in Real-Time with Splunk Collect, index and harness all the fast moving IT data generated by your applications, servers and devices whether physical, virtual or in the cloud. Deliver compliance at lower cost and gain new business insights. Free Software Download: http://p.sf.net/sfu/splunk-dev2dev _______________________________________________ perfmon2-devel mailing list perfmon2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/perfmon2-devel
