From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 9C71C40B6F2 for ; Tue, 30 Jun 2026 13:59:56 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.129.124 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782827997; cv=none; b=YVzRL+WE+3prcXSpf+5+f9qCVZATVSng2wWYOxrD17sMljH6EiSMOEnduWef+37YPshvfOs+WNFVlXtDree6kJNLdt7Esz5wRO1qyHq7VIqFUbh5Jtgh8n7x9T82wFo5ayIxP8u5Rn1bCCYTaAW2T+LCs4tRxO5y0QWWI8oGLRI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782827997; c=relaxed/simple; bh=0tc3n1T+iP6UtVH2Bcubud4h5kSvkSwkUuQb0E6M6qk=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=XiuifWw0FzDXT4Hq4CRQhQMe4TZI6uB+/ZQFOvDH8L9TQ9aqUkesUwaC7Hjdm0H9UoYAgkqzojvVONl835ItHSPd8BaTWKEmcidtBWiZYQBidvWYGGZ5Ed0nRaqLIOtTq8Qzh7sCoRCChBQMhq76Xi4hu5EfBc8zrD7KlCkpIGw= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=bInivByo; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b=jwZJMmbn; arc=none smtp.client-ip=170.10.129.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="bInivByo"; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b="jwZJMmbn" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1782827995; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=CXNz1TXGf+nGNIC0QUsV7H5j6lVbiMDLBDuaqoAEfSs=; b=bInivByobPbow8p/IBQh2WCXPKcDv7DLLA2o8ZwyUoTC1DrYwR/mcTGUnkGjMcoCxk3Jk0 ug82NKyFOTf4dVJeNcjXRarM1UQIvQKMtDA2YIUkMxO0UHFYWjtyV1j0lO3jqzl+kqN0+b fvYSAXUJWsGgDN2LdAVXrRxCtLfHYj8= Received: from mail-wr1-f69.google.com (mail-wr1-f69.google.com [209.85.221.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-689-cKz2XXxyOv28lpMr6EoxSw-1; Tue, 30 Jun 2026 09:59:53 -0400 X-MC-Unique: cKz2XXxyOv28lpMr6EoxSw-1 X-Mimecast-MFC-AGG-ID: cKz2XXxyOv28lpMr6EoxSw_1782827992 Received: by mail-wr1-f69.google.com with SMTP id ffacd0b85a97d-46e090a1232so515117f8f.3 for ; Tue, 30 Jun 2026 06:59:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=google; t=1782827992; x=1783432792; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:message-id:date:references :in-reply-to:subject:cc:to:from:from:to:cc:subject:date:message-id :reply-to; bh=CXNz1TXGf+nGNIC0QUsV7H5j6lVbiMDLBDuaqoAEfSs=; b=jwZJMmbnHC3St7exNGJXIJ99jUrDMC+2k2F5jRoq9g0L/Uu2nsuJbHsVgXY4PGxs6R VTXZWkNwZ1B1q06ZtwJwNVtUSBvR3b586CIMSyxtNPN1NW4Re6fLhozG6UzjZftzqz95 kRS4FsuU41ja/nhxuAyrVwqZWZ7RT+z41Y6cgPAawtx/ynql9pzfvGIVIqP0Bi8f2JYr FgLrI9QZcLKk1HirLzjNYVjZ7Ffu97EsdhA0jm1seYMXWeFTxHfB3IJLCak+GM6V5V5L kNyUOoNj7SlIAwFPLd+hLcCpLkLd2xZJWZfOC3tNmRL+5/Z4b95T1YqkkW4zNNNsq/w7 IAcw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1782827992; x=1783432792; h=content-transfer-encoding:mime-version:message-id:date:references :in-reply-to:subject:cc:to:from:x-gm-gg:x-gm-message-state:from:to :cc:subject:date:message-id:reply-to; bh=CXNz1TXGf+nGNIC0QUsV7H5j6lVbiMDLBDuaqoAEfSs=; b=NPcTT9BwLahKGeIZd8vMGxhp5rL15jenZtY3IBgNe5DAnxJt7R4TWrzjboz/N9NSTn F2EOCUtDjGH8Tj77UGfvMqeZSyeNapmBdC6gB5xWHVSiWHL1QUTlE8HZJ5/vTVKnRAZ9 5K+yLIhNlRmTp9iJC9ac0hNORS8WjXX7LJMU2szq0eLkTArrlyeLol9Rc5LV2a4EuQ86 wY1aMI4UbHWKzunwlgUrm4kn5PTgX7dOdVlNosL+VESuiTRkilr+P8/aAJMaVhhEn0Ek he4ropnChk1YYUzsqcBe2f0J6p5MxTjI+NfnHBNY/zSCFq1cqJ04Dj5F7pK2huPsOeBl 0z/g== X-Gm-Message-State: AOJu0Yy+H0yPXSIYMSltBF/HQcjnAZgNQPoL1kCgvS5LsZw2vcX0i584 lbbLJ9h8kFl4Zcc6QNXwP0zWY9jNYNX4xcFaLYqYU0UBx0xEeeGKAadmgPOxtKAl88jNCJrx2C5 b3ePQAoa0Rgk0i4tw5hlSvqAuFtSEXuhyWp6cNWsTcqundqF1UlD5TvQF+QZ82aICBg== X-Gm-Gg: AfdE7ckEgn+zsRMt5WcUN+C9Vzkq+K7c037gA06AZFPQgnqLcl81BY/M12EGWWObnkl aDL8pG52aCBjtWrilGLeIzeCXCwyLu28369vTeMOBuQaYncv8iwpf3Yrdk189MkFI5gshOjqxCS HeJMNfnFpM2pwg9cMoYx83A6NAsiCzdH7o5l7x+gDdbpxD/2BjmzMMJCNnLszFarMOhkcMiqMFa WlnxZ9hLJgnvpnieQ1L7A8APmWYWetDS6MHsn+fEsQY5UPxDGWH32pGe0aNoXg75uS/0RXzIqsV CbkNRwtRy+48G/JBNjHxlY+7GaFrkYBkiSbpy27QxvK8YIqVlHEeiCvW6a7BTzt5ObHYjgxsu4Z r35TFfUxyKatrD8wegoLljNFTu3x9FLlA4tEquS9LY9WhBpl6Y1KgdsRq1Mt3PK8x8TiWS67X X-Received: by 2002:adf:e009:0:10b0:474:b9d1:3203 with SMTP id ffacd0b85a97d-47657d2db45mr841021f8f.7.1782827992430; Tue, 30 Jun 2026 06:59:52 -0700 (PDT) X-Received: by 2002:adf:e009:0:10b0:474:b9d1:3203 with SMTP id ffacd0b85a97d-47657d2db45mr840981f8f.7.1782827991959; Tue, 30 Jun 2026 06:59:51 -0700 (PDT) Received: from vschneid-thinkpadt14sgen2i.remote.csb (213-44-135-146.abo.bbox.fr. [213.44.135.146]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-4756778fac3sm7443270f8f.32.2026.06.30.06.59.50 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 30 Jun 2026 06:59:51 -0700 (PDT) From: Valentin Schneider To: Tomas Glozar Cc: linux-kernel@vger.kernel.org, linux-trace-kernel@vger.kernel.org, Steven Rostedt , Masami Hiramatsu , Mathieu Desnoyers , Costa Shulyupin , Crystal Wood , John Kacur , Ivan Pravdin , Jonathan Corbet Subject: Re: [RFC PATCH v2 4/4] rtla/osnoise: Leverage IPI event filters when tracing a subset of CPUs In-Reply-To: References: <20260617131803.2988989-1-vschneid@redhat.com> <20260617131803.2988989-5-vschneid@redhat.com> Date: Tue, 30 Jun 2026 15:59:50 +0200 Message-ID: Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 30/06/26 12:14, Tomas Glozar wrote: > st 17. 6. 2026 v 15:18 odes=C3=ADlatel Valentin Schneider > napsal: >> @@ -406,6 +408,33 @@ struct osnoise_tool *osnoise_init_top(struct common= _params *params) >> goto out_err; >> } >> >> + /* >> + * If tracing on a subset of possible CPUs, leverage the kernel = filtering >> + * infrastructure to only generate events on traced CPUs. >> + */ >> + if (params->cpus) { >> + char filter[MAX_PATH]; >> + >> + snprintf(filter, ARRAY_SIZE(filter), "cpu & CPUS{%s}\n",= params->cpus); >> + retval =3D tracefs_event_file_write(tool->trace.inst, >> + "ipi", "ipi_send_cpu",= "filter", >> + filter); >> + if (retval) { > > retval is the number of bytes written here, so this should be "retval > < 0" like in trace_event_enable_filter() in trace.c. Same below. > According to the docstring: * Return 0 on success, and -1 on error. but regardless yes that should be a '< 0' check to match existing code. >> + err_msg("Could not set ipi_send_cpu CPU filter\n= "); >> + goto out_err; > > It would be useful to have --ipi work even on older kernels that don't > yet have your cpumask trace event filter patchset [1], for example, by > printing a debug message that filtering is disabled and setting a flag > instead of erroring out here. Then the code in > osnoise_ipi_cpu_handler() can preserve the CPU_ISSET check if the flag > is set. > > As --ipi is optional, we can choose to only support it on newer > kernels, but it would be nice to have it working without the filter, > too. > > [1] https://lore.kernel.org/linux-trace-kernel/20230707172155.70873-1-vsc= hneid@redhat.com/T/#u > Makes sense, will do. >> + } >> + >> + >> + snprintf(filter, ARRAY_SIZE(filter), "cpumask & CPUS{%s}= \n", params->cpus); >> + retval =3D tracefs_event_file_write(tool->trace.inst, >> + "ipi", "ipi_send_cpuma= sk", "filter", >> + filter); >> + if (retval) { >> + err_msg("Could not set ipi_send_cpumask CPU filt= er\n"); >> + goto out_err; >> + } > > Same two comments above apply here. > >> + } >> + >> tep_register_event_handler(tool->trace.tep, -1, "ipi", "ipi_send= _cpu", >> osnoise_ipi_cpu_handler, NULL); >> >> -- >> 2.54.0 >> > > I was thinking that it might make sense to enable the filters also for > the trace output instance. On the other hand, it would make it > difficult to enable the event without the filter then, as specifying > "-e ipi" or similar only re-enables the event but does not remove the > filter. Maybe the better idea is to implement an option to filter any > event enabled through -e/--event only to the measurement CPU, as a > separate feature. > I had actually forgotten about applying the filters for the output instance... I'll look into it. > Tomas