From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 5CC75C433EF for ; Mon, 11 Apr 2022 22:22:09 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1350436AbiDKWYV (ORCPT ); Mon, 11 Apr 2022 18:24:21 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:49762 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232202AbiDKWYT (ORCPT ); Mon, 11 Apr 2022 18:24:19 -0400 Received: from mail-io1-xd2c.google.com (mail-io1-xd2c.google.com [IPv6:2607:f8b0:4864:20::d2c]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E41376445; Mon, 11 Apr 2022 15:22:00 -0700 (PDT) Received: by mail-io1-xd2c.google.com with SMTP id 125so20352002iov.10; Mon, 11 Apr 2022 15:22:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=sVrk99jK5gTxl0PxzjdJZQxsj8dU0oJ85F8Hhavp+iQ=; b=IDzHXOtiq49zpd6i3rO4En/xTuVuDQozx+2ZlXg/2PjrcZLN0zv1Lib0RYxTc99yRn MJzx2OQr/27DngFWWRLEKzjYfce5In/L1UiVgBgTn75qg3JBUP20ngwTyPj3K0qRso/2 Wtx6Y3xvMqNIq+6o7wKbPCVWqnvUr+jmZp6hCHQ0ZPIsG8CNSlmdNR8JQm7H/n78l0LT /+mEdVk91PG5+H77rQyXCIMRUmSBpSjHnohkI5Vk3uPI//X4lC3Cir+ZEn2N+2/i1tEA RqXfMJU3Gl+DEkglYplUoDHL9XA5lSgrephUYGpwCT7TkOUjqVqoV453dj9B3+mSaals 6mPA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=sVrk99jK5gTxl0PxzjdJZQxsj8dU0oJ85F8Hhavp+iQ=; b=b96NcSzDg4HnnDRZ9FyQv05RNp/u8f4w5RRktFHT6FUdnZ6N89GoqekiJr65RATVqk VcGcS3zTtVp0R0n3k0XWe0l77sPbUl5nvOJh4KdbVwC2/uIbWMqTtlrcV569emvUIVti xjNooOkuLOp+vs//JrvNWs8Snis2EjKhWSMdptmQYx7T8LcgiTmBUY/Qxo/FFtYSfVjp i2CspF2k5ZSpoTe/38wGJU6urapCykgJudtQbSq1fg7tK33A8RRw7SQzf0YFzecpSjen 2XaDl3PFz+UwCz2l5bQiIReeSz3VOLYv02cxN2xRIoD07Yi9UPcpwZe0E9L3GjEC5H4I fx8w== X-Gm-Message-State: AOAM531+SGxQfSvj2JGaaWjE2dLFu5QwVaYLeenVjyFoJ0128W2wUD01 IBb2/7s0k2YkNEvINQUIOKWpmQHencBYOa0Nsfw= X-Google-Smtp-Source: ABdhPJw9XPMkEqORTNjHBOAB03SPoNqX6ianDhxyxywfgFDVskJEzt2devdZllPujqXGxj0NrzDiWRLgaxDi9eahETU= X-Received: by 2002:a05:6602:3c6:b0:63d:cac9:bd35 with SMTP id g6-20020a05660203c600b0063dcac9bd35mr14274524iov.144.1649715720304; Mon, 11 Apr 2022 15:22:00 -0700 (PDT) MIME-Version: 1.0 References: <20220407125224.310255-1-jolsa@kernel.org> <20220408232922.mz2vi2oaxf2fvnvt@MBP-98dd607d3435.dhcp.thefacebook.com> In-Reply-To: From: Andrii Nakryiko Date: Mon, 11 Apr 2022 15:21:49 -0700 Message-ID: Subject: Re: [RFC bpf-next 0/4] bpf: Speed up symbol resolving in kprobe multi link To: Alexei Starovoitov Cc: Jiri Olsa , Jiri Olsa , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , Masami Hiramatsu , Networking , bpf , lkml , Martin KaFai Lau , Song Liu , Yonghong Song , John Fastabend , KP Singh Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Apr 11, 2022 at 3:18 PM Alexei Starovoitov wrote: > > On Mon, Apr 11, 2022 at 10:15 PM Andrii Nakryiko > wrote: > > > > On Sat, Apr 9, 2022 at 1:24 PM Jiri Olsa wrote: > > > > > > On Fri, Apr 08, 2022 at 04:29:22PM -0700, Alexei Starovoitov wrote: > > > > On Thu, Apr 07, 2022 at 02:52:20PM +0200, Jiri Olsa wrote: > > > > > hi, > > > > > sending additional fix for symbol resolving in kprobe multi link > > > > > requested by Alexei and Andrii [1]. > > > > > > > > > > This speeds up bpftrace kprobe attachment, when using pure symbols > > > > > (3344 symbols) to attach: > > > > > > > > > > Before: > > > > > > > > > > # perf stat -r 5 -e cycles ./src/bpftrace -e 'kprobe:x* { } i:ms:1 { exit(); }' > > > > > ... > > > > > 6.5681 +- 0.0225 seconds time elapsed ( +- 0.34% ) > > > > > > > > > > After: > > > > > > > > > > # perf stat -r 5 -e cycles ./src/bpftrace -e 'kprobe:x* { } i:ms:1 { exit(); }' > > > > > ... > > > > > 0.5661 +- 0.0275 seconds time elapsed ( +- 4.85% ) > > > > > > > > > > > > > > > There are 2 reasons I'm sending this as RFC though.. > > > > > > > > > > - I added test that meassures attachment speed on all possible functions > > > > > from available_filter_functions, which is 48712 functions on my setup. > > > > > The attach/detach speed for that is under 2 seconds and the test will > > > > > fail if it's bigger than that.. which might fail on different setups > > > > > or loaded machine.. I'm not sure what's the best solution yet, separate > > > > > bench application perhaps? > > > > > > > > are you saying there is a bug in the code that you're still debugging? > > > > or just worried about time? > > > > > > just the time, I can make the test fail (cross the 2 seconds limit) > > > when the machine is loaded, like with running kernel build > > > > > > but I couldn't reproduce this with just paralel test_progs run > > > > > > > > > > > I think it's better for it to be a part of selftest. > > > > CI will take extra 2 seconds to run. > > > > That's fine. It's a good stress test. > > > > I agree it's a good stress test, but I disagree on adding it as a > > selftests. The speed will depend on actual host machine. In VMs it > > will be slower, on busier machines it will be slower, etc. Generally, > > depending on some specific timing just causes unnecessary maintenance > > headaches. We can have this as a benchmark, if someone things it's > > very important. I'm impartial to having this regularly executed as > > it's extremely unlikely that we'll accidentally regress from NlogN > > back to N^2. And if there is some X% slowdown such selftest is > > unlikely to alarm us anyways. Sporadic failures will annoy us way > > before that to the point of blacklisting this selftests in CI at the > > very least. > > Such selftest shouldn't be measuring the speed, of course. > The selftest will be about: > 1. not crashing > 2. succeeding to attach and getting some meaningful data back. Yeah, that's totally fine with me. My biggest beef is using time as a measure of test success, which will be flaky. Just a slow-ish test doing a lot of work sounds totally fine.