Fwd: systemtap global var lead to high cpu

[Arkady]

Hi Kun,

I avoid locks by using lockless data structures. For example, I have
my own hashtables instead of associative arrays.
You can check this code for inspiration
https://github.com/larytet/lockfree_hashtable

If the performance is paramount for your task you can switch to 100%
handwritten C code.

Arkady,

On Fri, Jul 24, 2020 at 5:01 AM Kun via Systemtap
<systemtap@sourceware.org> wrote:
>
> My global var saved is string type, not number, so I can not use aggregate.
> FChE will fixed this bug,
> https://sourceware.org/bugzilla/show_bug.cgi?id=26296
> Hoping to fixed soon.
>
>
>
>
> ------------------ Original ------------------
> From: Serhei Makarov <smakarov@redhat.com>
> Date: Thu,Jul 23,2020 10:22 PM
> To: systemtap <systemtap@sourceware.org>, mingkunone <mingkunone@qq.com>
> Subject: Re: Fwd: systemtap global var lead to high cpu
>
>
>
> Forwarding your question to systemtap@sourceware.org in case other people have suggestions.
>
>
>
> In general, the locks protect concurrent modifications from interfering with each other when different processes trigger the same probe.
>
>
> Depending on what  you want to do with the iphdr value, you may be able to reduce contention by using statistical aggregates
> (which do not require locking). For example, aaa[iphdr] <<< some_statistic; in a later probe iterate through aaa. A lot of the SystemTap example scripts use this type of structure, for example: https://sourceware.org/systemtap/examples/network/netfilter_summary.stp
>
>
> Otherwise, every tcp_ack() for every packet on your system will try to grab the same lock. The resulting CPU load is unsurprising to me.
>
>
> Hope this information is helpful; if not, someone else may have a better suggestion.
>
>
> All the best,
>       Serhei
>
>
> ---------- Forwarded message ---------
> From: Kun <mingkunone@qq.com>
> Date: Wed, Jul 22, 2020 at 11:24 PM
> Subject: systemtap global var lead to high cpu
> To: smakarov <smakarov@redhat.com>
>
>
>
> Hi,
>     I have a problem of system tap which
>  Using global var.
>     A simple demo as following,
> Global aaa
> Probe kernel.function(“tcp_ack”){
>     Iphdr = __get_skb_iphdr($skb)
>     If(iphdr == 0){
>         aaa=iphdr
>     }
>
>
> Then our env have a 10Gbps flow, and our cpu is nearly 100%.
>
>
> Analysising c code, I find this is because of a lock as following:
> Static void probe_6330()
> {
> If(sta_lock_probe(lock, ARRAY_SIZE(locks))
>     Return;
> If(l->iphdr == 0){
>     Global(s_global_aaa)=l->l_iphdr;
> }
>
>
> My question is that aaa should be protected in “if”,
> Why is the lock directly at the function entry?