| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <CABPqkBQyZfSczhAROdH8p0_asy=c2AJho4Kv9wRYabaLNKkURA@mail.gmail.com> Date: Wed, 16 May 2012 09:41:47 +0200 From: Stephane Eranian <eranian@...gle.com> To: David Ahern <dsahern@...il.com> Cc: linux-kernel@...r.kernel.org, peterz@...radead.org, mingo@...e.hu, acme@...hat.com Subject: Re: [PATCH v2 4/5] perf record: add meta-data support for pipe-mode On Wed, May 16, 2012 at 5:34 AM, David Ahern <dsahern@...il.com> wrote: > On 5/15/12 5:28 AM, Stephane Eranian wrote: >> >> This patch adds the meta-data header support for perf record >> when used in pipe mode: perf record -o - >> >> Up until now, meta-data was only available when perf record >> was used in "regular" mode, i.e., generating a perf.data file. >> For users depending on pipe mode, no host, event header information >> was gathered. This patch addresses this limitation. >> >> The difficulty in pipe mode is that information needs to be written >> sequentially to the pipe. Meta data headers are usually generated >> (and also expected) at the beginning of the file (or piped output). >> To solve this problem, we introduce new synthetic record types, >> one for each meta-data type. The approach is similar to what >> is already used for BUILD_ID and TRACING_DATA. >> >> We have modified util/header.c such that the same routines are used >> to generate and read the meta-data information regardless of pipe-mode >> vs. regular mode. To make this work, we added a new struct called >> feat_fd which encapsulates all the information necessary to read or >> write meta-data information to a file/pipe or from a file/pipe. >> >> It should be noted that there is a limitation with the current >> perf in terms of endianess in pipe mode. Perf assumes the records >> are generated using the same endianess during collection and >> analysis. That is always the case with the example shown below. >> However, one could also do: >> $ perf record -o - noploop 2 | perf inject -b>perf.data >> $ cat perf.data | perf report -i - >> >> With this patch, it is possible to get: >> $ perf record -o - noploop 2 | perf inject -b | perf report -i - >> # ======== >> # captured on: Fri Jan 20 18:13:55 2012 >> # ======== >> # >> # hostname : quad >> # os release : 3.2.0-rc7-tip >> # perf version : 3.2.0 >> # arch : x86_64 >> # nrcpus online : 4 >> # nrcpus avail : 4 >> # cpudesc : Intel(R) Core(TM)2 Quad CPU Q6600 @ 2.40GHz >> # cpuid : GenuineIntel,6,15,11 >> # total memory : 8092884 kB >> ... >> # HEADER_CPU_TOPOLOGY info available, use -I to display >> noploop for 2 seconds >> [ perf record: Woken up 1 times to write data ] >> [ perf record: Captured and wrote 0.084 MB - (~3677 samples) ] >> 99.80% noploop noploop [.] noploop >> 0.19% noploop [kernel.kallsyms] [k] radix_tree_gang_lookup >> >> Signed-off-by: Stephane Eranian<eranian@...gle.com> > > > I love the feature and it works nicely, but there has been push back on > adding more synthesized events. Also the size of the patch is a bit much to > take in. If there is no objection to the synthesized can you break the patch > up -- e.g., introduce the events in one, synthesis and processing functions > in another, plug into the commands, ... > Without new synthesized events, you cannot make this work. This is by construction of the pipe mode. Meta-data has be be injected in the stream and therefore it needs PERF_RECORD_* types. > David -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists