labath accepted this revision. labath added inline comments. This revision is now accepted and ready to land.
================ Comment at: lldb/test/API/tools/intel-features/intel-pt/test/TestIntelPTSimpleBinary.py:50-54 + "rand", # We expect to see a reference to the rand function + # within the last instructions + hex(fun_start_adddress), # We expect to have seen the first + # instruction of 'fun' + "at main.cpp:21" # We expect to see the exit condition of ---------------- wallace wrote: > labath wrote: > > labath wrote: > > > clayborg wrote: > > > > can we guarantee we will see any of these on a fully loaded machine > > > > running many tests simultaneously? Maybe we need to settle for the > > > > header of the output only to know that it tried to display something? > > > better avoid referencing functions from the system library... makes the > > > test more hermetic > > What exactly is the case you're worried about? I'm not very familiar with > > how all this works, but I would think that the kernel trace buffer for this > > is application specific, and is automatically switched off when the os > > schedules a different process (anything else would be a security breach). > > If that is true, then we should have pretty good control over what goes > > into the buffer, and we can ensure that it is: (a) big enough; and/or (b) > > application does not execute too much code and overflows it (not calling > > rand would help us get a reasonable upper bound on that). > > > > (Nonetheless it would be good to run some stress tests to verify this is > > stable.) > This is how it works: by default Intel PT has to be enabled on each logical > CPU, where it traces everything, regardless of which thread if running. The > kernel has the ability to switch Intel PT on and off on each logical CPU > whenever there's a thread context switch, and this kind of filtering is what > this LLDB plugin is using. > > For some context, that kind of filtering is expensive because of the constant > enabling/disabling of Intel PT and could incur in up to 5% total CPU cost > according to Intel. Another drawback of this approach is that threads spawned > by an already traced thread are not traced by default. The user has to enable > filtered tracing explicitly for these threads. > > A faster approach is to enable Intel PT on all CPUs without filtering. That > leads to a ~2% total CPU cost according to some tests some colleagues and I > ran. However, this needs having a secondary trace of context switches to be > able to attribute Intel PT packets to individual threads. We are not > following that approach in this plugin because of the added complexity. > However, I plan to make this plugin flexible enough to be able to load Intel > PT traces collected by other mechanisms which can do global tracing correctly. > > Lastly, the PT Trace unit in the cpu writes PT packets on memory without > interrupting the CPU itself nor the kernel. The only case in which packets > couldn't be written is when the BUS is completely full. However, this is > extremely rare and the CPU would retry later. > > ------------------------- > That being said, I see no reason why the trace wouldn't be collected at that > point. Just in case I'll add a 0.1 ms wait time for the CPU to have enough > time to send all the packets, which should be more than enough. Ok, that sounds good to me, though I'd be very surprised if 100ms makes any difference -- I've seen flaky tests with much bigger delays. ================ Comment at: lldb/test/API/tools/intel-features/intel-pt/test/main.cpp:2-8 +//// +//// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions. +//// See https://llvm.org/LICENSE.txt for license information. +//// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception +//// +////===----------------------------------------------------------------------===// +// ---------------- wallace wrote: > labath wrote: > > We're not putting license headers on tests. > > > > (Do these get automatically created by some IDEs or something? Can they be > > configured not to do that?) > I just copy pasted it from another test Which one? I don't see any test like that in the lldb repo. Was it from the swift fork or something? Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D77107/new/ https://reviews.llvm.org/D77107 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
