Fwd: systemtap global var lead to high cpu

[Serhei Makarov <smakarov@redhat.com>]

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?

------------------------------