On Tue, Aug 27, 2024 at 8:55 PM Masami Hiramatsu wrote:
>
> On Tue, 13 Aug 2024 13:34:09 -0700
> Andrii Nakryiko wrote:
>
> > trace_uprobe->nhit counter is not incremented atomically, so its value
> > is questionable in when uprobe is hit on multiple CPUs simultaneously.
> >
> > Also, doing this
On Tue, 13 Aug 2024 13:34:09 -0700
Andrii Nakryiko wrote:
> trace_uprobe->nhit counter is not incremented atomically, so its value
> is questionable in when uprobe is hit on multiple CPUs simultaneously.
>
> Also, doing this shared counter increment across many CPUs causes heavy
> cache line bou
On Tue, 13 Aug 2024 13:34:09 -0700
Andrii Nakryiko wrote:
> trace_uprobe->nhit counter is not incremented atomically, so its value
> is questionable in when uprobe is hit on multiple CPUs simultaneously.
>
> Also, doing this shared counter increment across many CPUs causes heavy
> cache line bou
On Tue, Aug 13, 2024 at 01:34:09PM -0700, Andrii Nakryiko wrote:
> trace_uprobe->nhit counter is not incremented atomically, so its value
> is questionable in when uprobe is hit on multiple CPUs simultaneously.
>
> Also, doing this shared counter increment across many CPUs causes heavy
> cache lin
On Tue, Aug 13, 2024 at 1:34 PM Andrii Nakryiko wrote:
>
> trace_uprobe->nhit counter is not incremented atomically, so its value
> is questionable in when uprobe is hit on multiple CPUs simultaneously.
>
> Also, doing this shared counter increment across many CPUs causes heavy
> cache line bounci
trace_uprobe->nhit counter is not incremented atomically, so its value
is questionable in when uprobe is hit on multiple CPUs simultaneously.
Also, doing this shared counter increment across many CPUs causes heavy
cache line bouncing, limiting uprobe/uretprobe performance scaling with
number of CP
6 matches
Mail list logo
