Fwd: systemtap global var lead to high cpu

[Kun]

Hi，
How to embed your module into systemtap？
it prompts some error when i run dup_probe.stp，
semantic error：while resolving probe point: identifier ‘kernel’ at kprocess.stp:29:25
    Source: probe kprocess.creat = kernel.function(“copy_process”).return
    Thank you




------------------ Original ------------------
From: Arkady <arkady.miasnikov@gmail.com>
Date: Fri,Jul 24,2020 11:49 AM
To: Kun <mingkunone@qq.com>
Cc: Serhei Makarov <smakarov@redhat.com>, systemtap <systemtap@sourceware.org>
Subject: Re: Fwd: systemtap global var lead to high cpu



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&gt;
> Date: Thu,Jul 23,2020 10:22 PM
> To: systemtap <systemtap@sourceware.org&gt;, mingkunone <mingkunone@qq.com&gt;
> 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&nbsp; 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,
> &nbsp;&nbsp;&nbsp; &nbsp; Serhei
>
>
> ---------- Forwarded message ---------
> From: Kun <mingkunone@qq.com&gt;
> Date: Wed, Jul 22, 2020 at 11:24 PM
> Subject: systemtap global var lead to high cpu
> To: smakarov <smakarov@redhat.com&gt;
>
>
>
> Hi,
> &nbsp; &nbsp; I have a problem of system tap which
> &nbsp;Using global var.
> &nbsp; &nbsp; A simple demo as following,
> Global aaa
> Probe kernel.function(“tcp_ack”){
> &nbsp; &nbsp; Iphdr = __get_skb_iphdr($skb)
> &nbsp; &nbsp; If(iphdr == 0){
> &nbsp; &nbsp; &nbsp; &nbsp; aaa=iphdr
> &nbsp; &nbsp; }
>
>
> 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))
> &nbsp; &nbsp; Return;
> If(l-&gt;iphdr == 0){
> &nbsp; &nbsp; Global(s_global_aaa)=l-&gt;l_iphdr;
> }
>
>
> My question is that aaa should be protected in “if”,
> Why is the lock directly at the function entry?