On 4/17/2023 9:01 PM, Wu, Fei wrote: > On 4/17/2023 8:11 PM, Alex Bennée wrote: >> >> "Wu, Fei" <fei2...@intel.com> writes: >> >>> On 4/11/2023 3:27 PM, Alex Bennée wrote: >>>> >>>> "Wu, Fei" <fei2...@intel.com> writes: >>>> >>>>> On 4/10/2023 6:36 PM, Alex Bennée wrote: >>>>>> >>>>>> Richard Henderson <richard.hender...@linaro.org> writes: >>>>>> >>>>>>> On 4/6/23 00:46, Alex Bennée wrote: >>>>>>>> If your aim is to examine JIT efficiency what is wrong with the current >>>>>>>> "info jit" that you can access via the HMP? Also I'm wondering if its >>>>>>>> time to remove the #ifdefs from CONFIG_PROFILER because I doubt the >>>>>>>> extra data it collects is that expensive. >>>>>>>> Richard, what do you think? >>>>>>> >>>>>>> What is it that you want from CONFIG_PROFILER that you can't get from >>>>>>> perf? >>>>>>> I've been tempted to remove CONFIG_PROFILER entirely. >>>>>> >>>>>> I think perf is pretty good at getting the hot paths in the translator >>>>>> and pretty much all of the timer related stuff in CONFIG_PROFILER could >>>>>> be dropped. However some of the additional information about TCG ops >>>>>> usage and distribution is useful. That said last time I had a tilt at >>>>>> this on the back of a GSoC project: >>>>>> >>>>>> Subject: [PATCH v9 00/13] TCG code quality tracking and perf >>>>>> integration >>>>>> Date: Mon, 7 Oct 2019 16:28:26 +0100 >>>>>> Message-Id: <20191007152839.30804-1-alex.ben...@linaro.org> >>>>>> >>>>>> The series ended up moving all the useful bits of CONFIG_PROFILER into >>>>>> tb stats which was dynamically controlled on a per TB basis. Now that >>>>>> the perf integration stuff was merged maybe there is a simpler series to >>>>>> be picked out of the remains? >>>>>> >>>>>> Fei Wu, >>>>>> >>>>>> Have you looked at the above series? Is that gathering the sort of >>>>>> things you need? Is this all in service of examining the translation >>>>>> quality of hot code? >>>>>> >>>>> Yes, it does have what I want, I suppose this wiki is for the series: >>>>> https://wiki.qemu.org/Features/TCGCodeQuality >>>> >>>> Yes. >>>> >>>>> >>>>> btw, the archive seems broken and cannot show the whole series: >>>>> https://www.mail-archive.com/qemu-devel@nongnu.org/msg650258.html >>>> >>>> I have a v10 branch here: >>>> >>>> https://github.com/stsquad/qemu/tree/tcg/tbstats-and-perf-v10 >>>> >>>> I think the top two patches can be dropped on a re-base as the JIT/perf >>>> integration is already merged. It might be a tricky re-base though. >>>> Depends on how much churn there has been in the tree since. >>>> >>> I have rebased the patches to upstream here: >>> https://github.com/atwufei/qemu/tree/tbstats >>> >>> I try to keep the patches as possible as they are, but there are lots of >>> changes since then, so changes are inevitable, e.g. CF_NOCACHE has been >>> removed from upstream, I just removed its usage in the corresponding >>> patch, which might not be preferred. >> >> Yeah that fine. CF_NOCACHE was removed to avoid special cases in the >> generation code - we simply don't link or store the TBs in the QHT >> anymore. As long as the guest isn't executing a lot of non-RAM code we >> won't run out of translation buffer too quickly. >> >>> >>> I did some basic tests and they worked (the output of info goes to qemu >>> console, instead of telnet terminal), including: >>> * tb_stats start >>> * info tb-list >>> * info tb 10 >>> >>> Alex, would you please take a look? >> >> That looks pretty good, glad it wasn't too painful a re-base. >> >> The next question is do you want to pick up the series and put through a >> review cycle or two to get merged? It would probably be worth checking >> the last posting thread to see if their are any outstanding review >> comments. >> > Yes, I can do it. I have something else in hand right now, so the review > request may be sent out in a few days. > I have sent the review out here, hope you have received it: https://www.mail-archive.com/qemu-devel@nongnu.org/msg955889.html
I just received the cover letter w/o the following patches, I do subscribe to qemu-devel@nongnu.org, not sure why. Thanks, Fei. > Thanks, > Fei.