[PATCH] D140063: [AutoFDO] Use getHeadSamplesEstimate instead of getTotalSamples to compute profile callsite staleness

Lei Wang via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Thu Dec 15 10:59:45 PST 2022


wlei added a comment.

In D140063#3998437 <https://reviews.llvm.org/D140063#3998437>, @wenlei wrote:

> In D140063#3998407 <https://reviews.llvm.org/D140063#3998407>, @hoy wrote:
>
>> In D140063#3998381 <https://reviews.llvm.org/D140063#3998381>, @wlei wrote:
>>
>>> In D140063#3998253 <https://reviews.llvm.org/D140063#3998253>, @wenlei wrote:
>>>
>>>> I thought the idea is to compute the % of samples being dropped due to mismatch? in this case, all samples from callsite will be dropped, so I actually don't see a problem with using getTotalSamples. Yes you can argue that they can be merged with base profile, but then that argument applies to getHeadSamplesEstimate too?
>>>
>>> Yeah, it's tricky to quantify the dropped callsite samples's impact. I was thinking in a reversed way, if we use `getTotalSamples`, I feel like the total samples are completely dropped(not merged into top-level profile), in fact it's still in use. And for `getHeadSamplesEstimate`, I feel it's like only the callsite call/jump's samples are dropped, but I admit that this's also not accurate, the missing inlining from big total samples could affect more on perf. I don't have strong opinion on this.
>>
>> Reporting mismatched samples based on `getHeadSamplesEstimate` sounds a bit more accurate to me, thought it's not perfect either. The direct effect of mismatched callsite samples is likely a missing inlining. Reporting callee total samples for this may not give a good signal, especially when the callee is really big but the callsite isn't very hot.
>>
>> We have some internal services showing a very high callsite mismatch rate like 30%. Wondering if that could be related.
>
> Logically I think a call site focused metric makes sense. But the way CallsiteSamples is defined led people to think this is total samples. I think perhaps we just need to be explicit in the naming, so it's clear that we're tracking call site counts, not call site samples..

Sounds good to change to the callsite counts. CallsiteSamples in the nested profile is indeed the total samples of the callee, which is a confusing name.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D140063/new/

https://reviews.llvm.org/D140063



More information about the llvm-commits mailing list