From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ot1-x341.google.com (mail-ot1-x341.google.com [IPv6:2607:f8b0:4864:20::341]) by sourceware.org (Postfix) with ESMTPS id 9C4763857C4F for ; Fri, 24 Jul 2020 03:49:56 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 9C4763857C4F Received: by mail-ot1-x341.google.com with SMTP id 72so6030713otc.3 for ; Thu, 23 Jul 2020 20:49:56 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=mKnK62SCL31BoqMlPqP9iH+loVV6JbmULz/iL3AB/1s=; b=W/fBVT6EJQCDtQLVOLXhy/SjXkGCP2hQSIFeM085bKKG7K1gGzRiUdHJ2ccx8EYgY7 QI2aZ01kKQhuNiim9+EDI/42tFmIPwFq0EHjXafSEoCJUMU2BBGarcTVl6CIXc4ymNdL juAaHuNbW+NVc+IbT/W/IjkwY+OodBlEL2TdYTNf+UvSvjzkNjOq1XF3kxLi71boc9G6 Q/XinEAVEpZOghNTq1o6ObqDw1/Hbf9GAihUsem3yGjEuHPyr644HkjO4qN+ftXCBp0J csZbmBCfqOFyQtDjr5hgjCEA8JS7v3zVjyxo6H8Df3zkamTKqdSujdMfEn4h3pTDENw2 AoGA== X-Gm-Message-State: AOAM531ns7QNGnNL0S+nB/dcRYzmh4Z0jH2+/dt+V1x2Rbpx27+eBFO8 c3tubQTAussNL0+OW/vsmatFqdiV8ghFDd6sVoY= X-Google-Smtp-Source: ABdhPJx4Y4TUaEBa2/+GQqh6Q2m3Bo50zLXC6UPZTDTv2qZShcQh9h8BOlKev+fWRlfFC4iwNzpC1RBOm2QQJ16NKgQ= X-Received: by 2002:a9d:7f82:: with SMTP id t2mr6785433otp.109.1595562596007; Thu, 23 Jul 2020 20:49:56 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Arkady Date: Fri, 24 Jul 2020 06:49:44 +0300 Message-ID: Subject: Re: Fwd: systemtap global var lead to high cpu To: Kun Cc: Serhei Makarov , systemtap Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-1.2 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: systemtap@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Systemtap mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jul 2020 03:49:58 -0000 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 wrote: > > My global var saved is string type, not number, so I can not use aggregat= e. > FChE will fixed this bug, > https://sourceware.org/bugzilla/show_bug.cgi?id=3D26296 > Hoping to fixed soon. > > > > > ------------------ Original ------------------ > From: Serhei Makarov Date: Thu,Jul 23,2020 10:22 PM > To: systemtap 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 w= ith each other when different processes trigger the same probe. > > > Depending on what  you want to do with the iphdr value, you may be a= ble to reduce contention by using statistical aggregates > (which do not require locking). For example, aaa[iphdr] <<< some_statisti= c; in a later probe iterate through aaa. A lot of the SystemTap example scr= ipts use this type of structure, for example: https://sourceware.org/system= tap/examples/network/netfilter_summary.stp > > > Otherwise, every tcp_ack() for every packet on your system will try to gr= ab 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 Date: Wed, Jul 22, 2020 at 11:24 PM > Subject: systemtap global var lead to high cpu > To: smakarov > > > Hi, >     I have a problem of system tap which >  Using global var. >     A simple demo as following, > Global aaa > Probe kernel.function(=E2=80=9Ctcp_ack=E2=80=9D){ >     Iphdr =3D __get_skb_iphdr($skb) >     If(iphdr =3D=3D 0){ >         aaa=3Diphdr >     } > > > 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 =3D=3D 0){ >     Global(s_global_aaa)=3Dl->l_iphdr; > } > > > My question is that aaa should be protected in =E2=80=9Cif=E2=80=9D, > Why is the lock directly at the function entry?