Re: [PATCH 2/2] perf/x86: Disable precise sampling for PERF_SAMPLE_STACK_USER

[Mi, Dapeng]

On 9/10/2026 3:30 AM, Namhyung Kim wrote:
> Hello,
>
> I missed this thread before sending my previous reply.
>
> On Wed, Sep 09, 2026 at 05:36:45PM +0800, Mi, Dapeng wrote:
>> On 9/9/2026 4:11 PM, Peter Zijlstra wrote:
>>> On Tue, Sep 08, 2026 at 01:56:56PM -0700, Ian Rogers wrote:
>>>> On Tue, Sep 8, 2026 at 8:10 AM Andi Kleen <ak@xxxxxxxxxxxxxxx> wrote:
>>>>>> That's what we already do, no? I have distinct memories of making the
>>>>>> stack unwind use the NMI regs rather then the PEBS regs.
>>>>>>
>>>>>>> In my opinion, it could even make the thing worse. User
>>>>>>> requires to get precise samplings, but perf silently returns imprecise
>>>>>>> records, this would mislead user.
>>>>>> Mostly just the unwind might be off a little, the rest is accurate. This
>>>>>> has been the case 'forever'. Performance analysis isn't for silly
>>>>>> people, if they can't deal with a little fuzz then perhaps they're in
>>>>>> the wrong business.
>>>>> Is the main problem that the stack doesn't agree? Perhaps there
>>>>> could be a check for regs->rsp == pebs->user rsp (if in user space)
>>>>> to detect problematic samples.
>>>>>
>>>>> The question is how to report it and who should do the checking.
>>>>>
>>>>> It may need new fields in the ABI either to communicate the extra PEBS RSP
>>>>> or a bit to indicate that there might be a mismatch.
>>>>>
>>>>> I guess checking in the kernel and reporting an error might be simpler
>>>>> and maybe cleaner, but it would likely limit more advanced recovery
>>>>> possibilities.
>>>>>
>>>>> Are there other mismatches that break the unwinding? Perhaps the same
>>>>> for RBP?
>>>> For DWARF unwinding any register may be the source of a frame pointer
>>>> (e.g. the OpenSSL library would use R11 rather than RBP).
>>>>
>>>> There is redundancy on x86 you can sample the PERF_REG_X86_IP register
>>>> in the user register and there is PERF_SAMPLE_IP in the sample event
>>>> itself.
>>>>
>>>> My understanding is that IBS can only sample IP and so for precise
>>>> samples we can use PERF_SAMPLE_IP as the precise location and the user
>>>> register PERF_REG_X86_IP as the interrupt IP - this would match the
>>>> other register values in the interrupt.
>>>>
>>>> In DWARF unwinding, we initialize the register state using the sampled
>>>> user registers:
>>> Oh, I had trouble reading yesterday :/ This is about USER_STACK, not
>>> CALLCHAIN.
>> Yes, this is about USR_STACK. The CALLCHAIN doesn't suffer this issue since
>> perf already returns an IP chain and user space can directly map them to
>> the symbols without depending on any register or stack snapshots. :)
>>
>>
>>> I think we should try very hard to not use USER_STACK, it is an
>>> abomination. Instead we really should improve CALLCHAIN to be more
>>> useful. There are a pile of patches for kernel based unwinders,
>>> including for .eh_frame (if only I had time to actually go look at
>>> them).
> That would be great!
>
>>> And we should probably look at doing a shadow stack based unwinder as
>>> well.
> Cool. It'd be nice to see that happen.
>
>>> This USER_STACK is really the absolute worst possible option. And
>>> perhaps refusing PEBS+USER_STACK makes sense.
>> If no others insist to implement the precise USER_STACK sampling (what Ian
>> suggested), I would give up for sending the drafted precise USER_STACK
>> sampling patches. Per my understanding, refusing precise USER_STACK
>> sampling what current version does is a cleaner and simpler way.
>> Supporting precise USER_STACK sampling inevitably complexes the PEBS/IBS
>> handling.
> I think precise is for IP and it's not clear if it applies to other REGS
> too.  But agree that it'd be simpler to reject.
>
>> BTW, currently perf tools already support the events creation fallback. As
>> long as user doesn't explicitly require precise USER_STACK sampling, the
>> USER_STACK sampling (--call-graph dwarf) would automatically fallback to
>> the PMI-based USER_STACK sampling after the initial precise USER_STACK
>> sampling try fails. So it won't really lead to the USER_STACK sampling fails. 
> That's true.  perf tools can fallback to auto-reduce the precise level
> unless it's requested manually.  If we go on this direction, I think we
> should mention this in the man page though.  Probably the condition is
> precise_ip + USER_REGS + USER_STACK.

Good idea. I would add an independent perf-tools patch to mention this once
we decide to go on this direction. Thanks.


>
> Thanks,
> Namhyung