From: Harald Servat <harald.servat@bsc.es>
To: Vince Weaver <vincent.weaver@maine.edu>
Cc: "linux-perf-users@vger.kernel.org" <linux-perf-users@vger.kernel.org>
Subject: Re: About using PEBS from the user space
Date: Mon, 04 May 2015 12:17:14 +0200 [thread overview]
Message-ID: <5547472A.5010908@bsc.es> (raw)
In-Reply-To: <alpine.DEB.2.11.1505031816450.4940@vincent-weaver-1.umelst.maine.edu>
[-- Attachment #1: Type: text/plain, Size: 3669 bytes --]
On 04/05/15 00:19, Vince Weaver wrote:
> On Mon, 4 May 2015, Harald Servat wrote:
>
>> Dear list,
>>
>> I'd like to use the perf library to access PEBS so as to collect referenced
>> memory addresses from the user space. I think I've successfully setup the perf
>> structures (struct perf_event_attr) to configure the performance counters, but
>> I don't see what should I do to access to the captured memory addresses. I've
>> seen that within arch/x86/kernel/cpu/perf_event_intel_ds.c there are the
>> routines alloc_pebs_buffer, alloc_ds_buffer which seems to allocate and setup
>> the necessary buffers using kmalloc_node calls. Question is, how can replicate
>> this from the user space? And how we should connect these buffers to the PEBS
>> infrastructure using perf calls?
>
> You can try looking at the example code in my perf_event_tests code.
> https://github.com/deater/perf_event_tests
>
> The stuff you are looking for is probably covered in the
> test/record_sample/samples_data_src
> test/record_sample/sample_weight
> and especially the
> test/record_sample/sample_regs_intr
> tests, although that last one requires a fairly recent kernel to work.
>
> Vince
Vince,
that is really interesting work, thank you! However, for some reason
the PEBS collected address is never shown (and maybe not captured)
according to the following partial output
PERF_RECORD_SAMPLE [c001], MISC=16386
(PERF_RECORD_MISC_USER,PERF_RECORD_MISC_EXACT_IP ), Size=32
PERF_SAMPLE_IP, IP: 404510
PERF_SAMPLE_WEIGHT, Weight: 30
PERF_SAMPLE_DATA_SRC, Raw: 68100242
Load Hit Line fill buffer No snoop Hit Level 1 TLB Level 2 TLB
PERF_RECORD_SAMPLE [c001], MISC=16386
(PERF_RECORD_MISC_USER,PERF_RECORD_MISC_EXACT_IP ), Size=32
PERF_SAMPLE_IP, IP: 404524
PERF_SAMPLE_WEIGHT, Weight: 76
PERF_SAMPLE_DATA_SRC, Raw: 68100442
Load Hit L2 cache No snoop Hit Level 1 TLB Level 2 TLB
PERF_RECORD_SAMPLE [c001], MISC=16386
(PERF_RECORD_MISC_USER,PERF_RECORD_MISC_EXACT_IP ), Size=32
PERF_SAMPLE_IP, IP: 404524
PERF_SAMPLE_WEIGHT, Weight: 77
PERF_SAMPLE_DATA_SRC, Raw: 68100842
Load Hit L3 cache No snoop Hit Level 1 TLB Level 2 TLB
I've looked into your code in order to compare it with the perf tool
and it looks like you support it in the code in the following lines of
lib/parse_record.c, so it looks that sample_type is not tagged with
PERF_SAMPLE_ADDR bit.
511 if (sample_type & PERF_SAMPLE_ADDR) {
512 long long addr;
513 memcpy(&addr,&data[offset],sizeof(long long));
514 if (!quiet) printf("\tPERF_SAMPLE_ADDR, addr:
%llx\n",addr);
515 offset+=8;
516 }
I tweaked a bit the perf dump application so that it prints the
sample_type and it always shows c10f whereas your binary prints c001. If
I simply go to one of the tests (say sample_data_src.c) and force
pe.sample = 0xc10f then it works (printing additional data). So, would
the following change make sense into your code to emit the sampled address?
Best regards.
WARNING / LEGAL TEXT: This message is intended only for the use of the
individual or entity to which it is addressed and may contain
information which is privileged, confidential, proprietary, or exempt
from disclosure under applicable law. If you are not the intended
recipient or the person responsible for delivering the message to the
intended recipient, you are strictly prohibited from disclosing,
distributing, copying, or in any way using this message. If you have
received this communication in error, please notify the sender and
destroy and delete any copies you may have received.
http://www.bsc.es/disclaimer
[-- Attachment #2: sample_data_src.c.patch --]
[-- Type: text/x-patch, Size: 531 bytes --]
diff --git a/tests/record_sample/sample_data_src.c b/tests/record_sample/sample_data_src.c
index 1c3d260..35c7e81 100644
--- a/tests/record_sample/sample_data_src.c
+++ b/tests/record_sample/sample_data_src.c
@@ -113,7 +113,7 @@ int main(int argc, char **argv) {
pe.size=sizeof(struct perf_event_attr);
pe.sample_period=SAMPLE_FREQUENCY;
pe.sample_type=PERF_SAMPLE_IP | PERF_SAMPLE_WEIGHT |
- PERF_SAMPLE_DATA_SRC;
+ PERF_SAMPLE_DATA_SRC | PERF_SAMPLE_ADDR ;
global_sample_type=pe.sample_type;
next prev parent reply other threads:[~2015-05-04 10:17 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-05-03 22:05 About using PEBS from the user space Harald Servat
2015-05-03 22:19 ` Vince Weaver
2015-05-04 8:13 ` Harald Servat
2015-05-04 10:17 ` Harald Servat [this message]
2015-06-25 16:00 ` Harald Servat
2015-06-25 19:06 ` Manuel Selva
2015-06-26 8:13 ` Harald Servat
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5547472A.5010908@bsc.es \
--to=harald.servat@bsc.es \
--cc=linux-perf-users@vger.kernel.org \
--cc=vincent.weaver@maine.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.