similar to: XRay feature – fdr log flushing

# Objective Implement an XRay mode 'xray-profiling' that gathers stack trace latencies/durations and builds histograms to provide basic statistics about where time is going in an execution of the application. # Background XRay has two modes currently implemented in compiler-rt: a basic (nee naive) mode and flight data recorder (FDR) mode. Basic mode logging, when enabled, will collect

FYI: Patch is now available for review in https://reviews.llvm.org/D44620. On Thu, Feb 15, 2018 at 1:34 PM Dean Michael Berris <dean.berris at gmail.com> wrote: > # Objective > > Implement an XRay mode 'xray-profiling' that gathers stack trace > latencies/durations and builds histograms to provide basic statistics about > where time is going in an execution of the

Hello, I’ve noticed that XRay does not report the PID in the trace log. Could this be added for multi-process support? (Maybe as a command line argument). Thanks, Henry -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180611/f800c333/attachment.html>

Hello, I am initializing FDR mode and finalizing/flushing the buffers manually. XRay does not log calls from the main thread unless there is a function call after __xray_log_finalize(). This behavior is abnormal since one would expect the trace file to contain all function calls made up to the point when __xray_log_finalize() is called. To demonstrate this behavior, I have taken the test case

I would be happy to help. Could you send me the example patch? Where would I submit my patch to be reviewed? Thanks, Henry On Mon, Jun 11, 2018 at 8:31 PM, Dean Michael Berris <dean.berris at gmail.com> wrote: > > > > On 12 Jun 2018, at 07:49, Henry Zhu via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > > > > Hello, > > > > > > I’ve

I'm still somewhat unclear about what you mean by "metadata record entry at the beginning of the block". I understand that I can make a MetadataRecord that contains the pid/tid since a metadata record contains 16 bytes. However, I don't understand what do you mean by the "beginning of the block". Do you mean right after the file header? My understanding is that at

On Sun, Mar 12, 2017, 4:10 PM Dean Michael Berris <dean.berris at gmail.com> wrote: > > > On 9 Mar 2017, at 09:32, David Blaikie via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > > > > I agree that we should clean up the standard library usage even just for > consistency. > > > > +1 -- now that I think about it, it should be fairly doable

On Wed, Mar 8, 2017 at 2:28 PM Tim Shen <timshen at google.com> wrote: > On Wed, Mar 8, 2017 at 1:49 PM David Blaikie <dblaikie at gmail.com> wrote: > > So I stumbled across an issue that I think is a bit fundamental: > > The xray runtime uses the C++ standard library. > > This seems like a problem because whatever C++ standard library is used to > compile the

Hello, There seems to be a bug with the value of the thread ID (TID) that is generated by XRay when calling fork(). The value of the TID of the child has the same TID as its parent (this is seen in the “thread: “ field of the YAML output produced by the llvm-xray tool). This is a problem as the trace generated contains the same TID for the parent and children processes, making it difficult to

Hi llvm-dev, Recently, we've committed the beginnings of the llvm-xray [0] tool which allows for conveniently working with both XRay-instrumented libraries as well as XRay trace/log files. In the course of the review for the conversion tool [1] which turns a binary/raw XRay log file into YAML for human consumption purposes, a question arose as to how we intend to allow users to develop tools

Hi llvm-dev, I've recently been working on improving the profiling mode for XRay in compiler-rt [0] and am ramping up efforts to do the same for flight-data recorder mode. The changes are generally in the direction of reducing the overheads (measured through benchmarks in the test-suite) and addressing some feature requests/bugs. In the interest of addressing these changes in a timely

I don't object to backporting the fix. But I think the FDR itself is not in 4.0 yet. Let Dean suggest how risky FDR may be: I see substantial code changes, but for the old code they seem to be mostly moving. Dean, if you're on vacation, I can submit the compare_exchange_strong() fix. Cheers, Serge On 27 January 2017 at 19:52, Renato Golin <renato.golin at linaro.org> wrote: >

Hi Dean, I haven't looked very closely at XRay so far, but I'm wondering if making CTF (common trace format, e.g. see http://diamon.org/ctf/) the default format for XRay traces would be useful? It seems it'd be nice to be able to reuse some of the tools that already exist for CTF, such as a graphical viewer (http://tracecompass.org/) or a converter library

So I stumbled across an issue that I think is a bit fundamental: The xray runtime uses the C++ standard library. This seems like a problem because whatever C++ standard library is used to compile the XRay runtime may not be the same as the C++ standard library (if any) that is used to build the target application and link XRay into. Does this make sense? Is this a problem? Talking to Chandler

On Wed, Nov 30, 2016 at 3:26 AM Renato Golin <renato.golin at linaro.org> wrote: > On 30 November 2016 at 05:08, Dean Michael Berris via llvm-dev > <llvm-dev at lists.llvm.org> wrote: > > - Is there a preference between the two options provided above? > > - Any other alternatives we should consider? > > - Which parts of which options do you prefer, and is there

On Sat, 3 Jun 2017 16:04:57 -0700 Tim Northover <t.p.northover at gmail.com> wrote: [snip] > I think you should be able to fix it by changing the > compiler-rt/lib/xray/test/CMakeLists.txt. If you find the > "add_compiler_rt_test" call and move "-lstdc++" to the end, just after > "-lrt" it should work. Thanks, Tim. I don't see "-lrt":

Hi, I am trying to build the LLVM suite on a RedHat Enterprise Linux clone (Scientific Linux <https://www.scientificlinux.org/>). In the latest attempt, the build seems to complete without any explicit failures but the `check-all` process fails. Any ideas about what is wrong or suggestions for how to proceed would be much appreciated. This is the current procedure: sudo yum install

On Tue, Mar 14, 2017 at 5:34 PM Dean Michael Berris <dean.berris at gmail.com> wrote: > On 13 Mar 2017, at 15:39, David Blaikie <dblaikie at gmail.com> wrote: > > > > On Sun, Mar 12, 2017, 4:10 PM Dean Michael Berris <dean.berris at gmail.com> > wrote: > > > > On 9 Mar 2017, at 09:32, David Blaikie via llvm-dev < > llvm-dev at

You asked the same question on the Bioconductor mailing list back in August. At that time, you suggested yourself a solution for how the adjusted p-values should be interpreted. I answered your query and told you that your interpretation was correct. So I'm not sure what more can be said, except that you should read the article Wright (1992), which is cited in the help entry for p.adjust(),

Yeah, I was being optimistic about this one. It should be changed to strong if he weak version doesn't quite do it. The other way to do this is to change the test to do the polling, but that seems sub-optimal. Sent from my iPhone > On 26 Jan 2017, at 5:10 am, Serge Rogatch via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Hi, > > Indeed, it seems that exactly this