Received: by 2002:a05:6602:2086:0:0:0:0 with SMTP id a6csp4426327ioa; Wed, 27 Apr 2022 03:43:18 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzauKzk6XmEPge6sKJffwvJzZknYEgpeFtIvHS2vIDQgw1zTpfKut7I0WSEO1snstHratmf X-Received: by 2002:a17:90b:17c9:b0:1da:4359:768b with SMTP id me9-20020a17090b17c900b001da4359768bmr1701111pjb.22.1651056198053; Wed, 27 Apr 2022 03:43:18 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1651056198; cv=none; d=google.com; s=arc-20160816; b=yTVu+N9VGWZCfIpkxC660bFSCe6/4RBRoEbxp5Lfm3zImlC3LavwUeGQ0ca1rFTjDt j9Ecuc0TKMAkpnSDZ5SmPYQOc7Icm9GcaipKzqO/HZEV1biPFWVvpZNZ6xh3M0OCk/XA yH1y8jC3EfF4VxkgWr2PkMj8s3+f8Mt+NwwPKB4pcjNJ8ctTipZE/wqk1DxWpN03peud QzFDadNYs8DHOwE8oIJMvBY8uW9o3TPupZNC2Yd46VyiFosk3ms5PYzMyofknPP4ys+q b0mB69TydWM0eI5CVbvOL3mvQSrk0Ij7Tya8QcJ16weBm9Ta1++2fLGiAEb4JOlZhOr/ q98w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=qfwjPLjHy0b+oJYbdqU408UT5vznIVKG78yOHQHkEGc=; b=j9JUw8/lA4uIo0/Or30IbmOKe4tbZXjifDHITmw2RkVKUd+n+niC6U5gHon2a81xLu 9IZGllOjoEvz0/LACS4S+s0T7kn7gMBgx01qRivuVea6vVEP5PtA1FnsRhELI0lvJ4+n t2ebL4yL427x/5qibr5Lxhh/XaxV+ECjuAr+S+nVkIRrEm3Mob5kXILNfO4yMIKR6t8g V31LcxTvfcVar4Ft6ZfC3T6KeThG9TQsCE0rxOLcXodvWuJ7A6E9k0U1p+nVcnRIjf+r OnpEU0iH4yjuyCNtyvNqWUo87fm55C6v9XqwwPbzTK6RbZPWNo79W0ESWaHf135tdBiw 63ew== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20210112 header.b=RNKx0HUL; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [23.128.96.19]) by mx.google.com with ESMTPS id q185-20020a6343c2000000b003ab7a1a4576si1235631pga.136.2022.04.27.03.43.17 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 27 Apr 2022 03:43:18 -0700 (PDT) Received-SPF: softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) client-ip=23.128.96.19; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20210112 header.b=RNKx0HUL; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id D087B3F7BB3; Wed, 27 Apr 2022 02:52:33 -0700 (PDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S243701AbiDZX6n (ORCPT + 99 others); Tue, 26 Apr 2022 19:58:43 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42188 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1356224AbiDZX6i (ORCPT ); Tue, 26 Apr 2022 19:58:38 -0400 Received: from mail-io1-xd29.google.com (mail-io1-xd29.google.com [IPv6:2607:f8b0:4864:20::d29]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 3260513D43; Tue, 26 Apr 2022 16:55:28 -0700 (PDT) Received: by mail-io1-xd29.google.com with SMTP id f4so761057iov.2; Tue, 26 Apr 2022 16:55:28 -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=qfwjPLjHy0b+oJYbdqU408UT5vznIVKG78yOHQHkEGc=; b=RNKx0HULjvM3tKDODOUDRyzTfZI3BekYtYdnI8r/uKPOQGni5wp+LnDXXynTOxk8DK OEWgAD31/oNFFZqkJQ1ZwGnoP/jnG+3UvBfuhkHMBRiI/euPg6tAR8Zx36xZEGo6Voi+ DuLZddf3osnx2XiJeS/C3TLm8/48JOHs5xDZ7SjxyJtwVu2cPGuUpHZ0Jy47PkPT+qIf yOfOo6JjbwQYecuAl2MORPj9jGta/n9Nzqgp5pdrQL5FiQUvJ0u47gHvs0HQdEFRTav+ J5jLJg4srAftX62Mjm7XjNIwALsozhT0GWA2jhtmppZ+HpHVBv8JQK4qr3Qd2nUz0qlx WozA== 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=qfwjPLjHy0b+oJYbdqU408UT5vznIVKG78yOHQHkEGc=; b=5RpkEQ6xF4lJkBbE07EoIGD/K0TrBZnwb2awYl3VTMt6H6ohpFUAH8/xS2dVXvQY9F u6sGF4tACcD6lAPlRDx6YE5ili5777uqeUq/YndokX4nGefNJlvK8Q2lPkn728x14FRe aaSn5kA3OlVEINcOKRd43o6SFEzVpiToSmrf/D7uTzQqe11WDbkYRf3UdP8Bkmnzk3Od lWY5br8ICosY5q0pq05nhyJkOFdfJGkxWIbiMBXzKKSYkLfpfgwdO6BK4jIq3yYbslG2 gmx/JN9Xv0fQco21FzoEqX7KSxBB0wyXDzJ0bScrGvEYfF/4ncSnhZkK4y9QWm+1YcHo M+zA== X-Gm-Message-State: AOAM532YI8zVnTFnmomqKXvOtMUygV1bUaVqDkR/21/HMiaAKNv71Ynx YvKCPxutPQc0OiWgK+bgwIowCowlmSSLsJ3daRg= X-Received: by 2002:a05:6638:3393:b0:32a:93cd:7e48 with SMTP id h19-20020a056638339300b0032a93cd7e48mr11034554jav.93.1651017328145; Tue, 26 Apr 2022 16:55:28 -0700 (PDT) MIME-Version: 1.0 References: <20220422150507.222488-1-namhyung@kernel.org> <20220422150507.222488-5-namhyung@kernel.org> In-Reply-To: <20220422150507.222488-5-namhyung@kernel.org> From: Andrii Nakryiko Date: Tue, 26 Apr 2022 16:55:17 -0700 Message-ID: Subject: Re: [PATCH 4/4] perf record: Handle argument change in sched_switch To: Namhyung Kim Cc: Arnaldo Carvalho de Melo , Jiri Olsa , Ingo Molnar , Peter Zijlstra , LKML , Andi Kleen , Ian Rogers , Song Liu , Hao Luo , bpf , "linux-perf-use." , Blake Jones Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-1.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RDNS_NONE, SPF_HELO_NONE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Apr 22, 2022 at 3:49 PM Namhyung Kim wrote: > > Recently sched_switch tracepoint added a new argument for prev_state, > but it's hard to handle the change in a BPF program. Instead, we can > check the function prototype in BTF before loading the program. > > Thus I make two copies of the tracepoint handler and select one based > on the BTF info. > > Signed-off-by: Namhyung Kim > --- > tools/perf/util/bpf_off_cpu.c | 32 +++++++++++++++ > tools/perf/util/bpf_skel/off_cpu.bpf.c | 55 ++++++++++++++++++++------ > 2 files changed, 76 insertions(+), 11 deletions(-) > [...] > > +SEC("tp_btf/sched_switch") > +int on_switch3(u64 *ctx) > +{ > + struct task_struct *prev, *next; > + int state; > + > + if (!enabled) > + return 0; > + > + /* > + * TP_PROTO(bool preempt, struct task_struct *prev, > + * struct task_struct *next) > + */ > + prev = (struct task_struct *)ctx[1]; > + next = (struct task_struct *)ctx[2]; you don't have to have two BPF programs for this, you can use read-only variable to make this choice. On BPF side const volatile bool has_prev_state = false; ... if (has_prev_state) { prev = (struct task_struct *)ctx[2]; next = (struct task_struct *)ctx[3]; } else { prev = (struct task_struct *)ctx[1]; next = (struct task_struct *)ctx[2]; } And from user-space side you do your detection and before skeleton is loaded: skel->rodata->has_prev_state = But I'm still hoping that this prev_state argument can be moved to the end ([0]) to make all this unnecessary. [0] https://lore.kernel.org/lkml/93a20759600c05b6d9e4359a1517c88e06b44834.camel@fb.com/ > + > + state = get_task_state(prev); > + > + return on_switch(ctx, prev, next, state); > +} > + [...]