From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wr1-f46.google.com (mail-wr1-f46.google.com [209.85.221.46]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 00D8439448E for ; Mon, 2 Mar 2026 10:02:58 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.46 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772445780; cv=none; b=SMPYmHLezM3hoH9+gAhRqTQXm9L342OGqr/RVGt5IMnvSuXjATnjPjmOEQxNuAzGI+KcmPOq16sG1NBjLPy+oHMzlUzAbfEnSQDoX786GhJjxUZBhK7GboW5ro3iEyGdKiwCZ7ojSS5mMsXXDRx9ce8v1CZbU2qvOYyVK59TCOA= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772445780; c=relaxed/simple; bh=FmP+8/STbZPXzEarN9WMRFo6PtmMjHYmrYB7jF0qsTE=; h=From:Date:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=FQdBb9KNfIQAu7w9oE4auWb0eVdVKt0erm4/w+QcIDJHobRstY89S+onf1eDQUMpeRF2UukmepcoXPMpS9tjU0b7MgMouGkPQbtY6aFfMJWC/1MbrmQaJQNtlnSjVXxhkq3Uq/3oBWVko7a8ZcWZasDo4/sIWZ2Y8WWoeSuDCiA= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=OWm1PeE7; arc=none smtp.client-ip=209.85.221.46 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="OWm1PeE7" Received: by mail-wr1-f46.google.com with SMTP id ffacd0b85a97d-439aa2f8ebaso981134f8f.2 for ; Mon, 02 Mar 2026 02:02:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1772445777; x=1773050577; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:date:from:from:to:cc:subject:date:message-id:reply-to; bh=JQjsYPyYtJcuqfg3UYRQSbPqvPqP/d/sBzajfqaJ+30=; b=OWm1PeE7Gh/mRGrMctu9/Yj2rcoLNMDvUgucZ0BJKJkcGPwQNiQuEDNgs6RdkqqXrC zrwfccNHc23v9vsGiFTlBIG9coQANam1QUiNvoSupPWJAkPg75LrzybP5TmGCOCPfILm DNELJKR8N4rjumEbcarPG8tzA5rGGiLgdA9H5OjRghh5pVHE3MapzCH8+6YpajZYmrMS l7VxGuf/I2lpQEx7vfsvAVyCsDE9ldjTfvyRnFqubm6/ZC6qcll9wlKjhC39Yz0cMXy7 EPpEd7UdPLDY3iTZjiBNe4I+t09ROVlGJAp14GN2MJQqYg2wG+Xl1y3tqr9lK0pkqEF9 b7XQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1772445777; x=1773050577; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:date:from:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=JQjsYPyYtJcuqfg3UYRQSbPqvPqP/d/sBzajfqaJ+30=; b=DL89TZY20zTGb0eFSzOFMreZ4lReUse2WhiiF/rIPKbKjXq7Lv2qzSb6k3uXPUVnvA J/1U2LQpvaR74uCxfGo01s6c5+tp9Qf3XErc2yHlzAbUWMUjnd7e2COnGbgR3jJPwYdg a4CIbO8AKGvmcwh91YV6h3U5GNocZsM4a22Kf1qFfgcdN649EHdxfdb3zx98JXEjri9z Brxifqy0sLmlnlMBM6me/0+wfp99z59ZNJJEp0zlZ3i+E0nKleDfkt/9quXU2yRTADRV LSrgSJtYh7UKQU7WvDQmBWZzgGLVzFY1GtO2YI/omB34cZ3s7rblPpl0ZLosP5pzzb4o Nbbg== X-Forwarded-Encrypted: i=1; AJvYcCWLWmYep1p+FZ/Tzf7ft16NGVehUj+Kk8IPmfiL+Ww70ThvXThBt+J7Ufj7afAuLU0cfwXrAjAZUqXHBXU=@vger.kernel.org X-Gm-Message-State: AOJu0Yw3/1hUdgzNUwEEIReDtG2LOxk50dlZ9IFBrUr+3StLGTf5u9Bu kzM/JcWykJSToiviEw9bZa/8yiiByXqoU3sKXqFFURlwKviz9jW3+obu X-Gm-Gg: ATEYQzxWGWv2VT5JVCONfwQdgZDx9IwsqKEFXkdcA3hRqkKYWhflTSM1QYe8P/2zyPm ah/5uaxUNjm8LF/k+CFcoaWN4BxlwjzcbB8kgkMb3+58617bvV1biO03YdIUpwB9NcWtKXSsEJ9 U9hQ0VwOOb6brbftxgDtdTSSwog7xHCpT/xPgBrrKZfcrbjDd7Ua3JGlVd8TvdwH9H6FhOkxSPt cUxJXKYB9ZU3NHNNphlQ6mmkdy669DarXHkAVV1XcmZ31N1nYyDz5BwR6FiBRcayq+6BjRnQ4Ty qBulhBZmAgOabxb9uzyn2ZcD4gqHtKr4Vo2SFYa2mgKepE10mfgRAvRYVLo5vY1LdIe9xWOOLq6 /VyTTRPqyXQ4yosHv5wBM94yJDifcdtquBQ8LKhWUlPbN4OKwvrLTalwF26HNHH5fXNxIBsoHBi MY9Oz89Hg= X-Received: by 2002:a05:6000:250d:b0:439:ae82:6ab2 with SMTP id ffacd0b85a97d-439ae826be5mr10588374f8f.57.1772445777056; Mon, 02 Mar 2026 02:02:57 -0800 (PST) Received: from krava ([2a02:8308:a00c:e200::d99c]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-439ac9f3e5bsm17099860f8f.37.2026.03.02.02.02.56 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 02 Mar 2026 02:02:56 -0800 (PST) From: Jiri Olsa X-Google-Original-From: Jiri Olsa Date: Mon, 2 Mar 2026 11:02:54 +0100 To: Sun Jian Cc: Andrii Nakryiko , Shuah Khan , Eduard Zingerman , Alexei Starovoitov , Daniel Borkmann , bpf@vger.kernel.org, linux-kselftest@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v2 2/2] selftests/bpf: bpf_cookie: make perf_event subtest trigger reliably Message-ID: References: <20260228074555.122950-1-sun.jian.kdev@gmail.com> <20260228074555.122950-3-sun.jian.kdev@gmail.com> 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=us-ascii Content-Disposition: inline In-Reply-To: <20260228074555.122950-3-sun.jian.kdev@gmail.com> On Sat, Feb 28, 2026 at 03:45:55PM +0800, Sun Jian wrote: > The perf_event subtest relies on SW_CPU_CLOCK sampling to trigger the BPF > program, but the current CPU burn loop can be too short on slower systems > and may fail to generate any overflow sample. This leaves pe_res unchanged > and makes the test flaky. > > Make burn_cpu() take a loop count and use a longer burn only for the > perf_event subtest. Also scope perf_event_open() to the current task to > avoid wasting samples on unrelated activity. > > Signed-off-by: Sun Jian > > --- > Changes in v2: > > Move the perf_event_open() argument change here from patch 1/2. > > v1: > --- > .../selftests/bpf/prog_tests/bpf_cookie.c | 19 +++++++++++-------- > 1 file changed, 11 insertions(+), 8 deletions(-) > > diff --git a/tools/testing/selftests/bpf/prog_tests/bpf_cookie.c b/tools/testing/selftests/bpf/prog_tests/bpf_cookie.c > index b7643a5bf7ad..35adc3f6d443 100644 > --- a/tools/testing/selftests/bpf/prog_tests/bpf_cookie.c > +++ b/tools/testing/selftests/bpf/prog_tests/bpf_cookie.c > @@ -6,6 +6,7 @@ > #include > #include > #include > +#include > #include > #include > #include > @@ -431,11 +432,12 @@ static void tp_subtest(struct test_bpf_cookie *skel) > bpf_link__destroy(link3); > } > > -static void burn_cpu(void) > +static void burn_cpu(long loops) nit, there's another burn_cpu in prog_tests/perf_link.c, we could add it to trace_helpers.c or test_progs.c > { > - volatile int j = 0; > + long j = 0; > cpu_set_t cpu_set; > - int i, err; > + long i; > + int err; > > /* generate some branches on cpu 0 */ > CPU_ZERO(&cpu_set); > @@ -443,9 +445,10 @@ static void burn_cpu(void) > err = pthread_setaffinity_np(pthread_self(), sizeof(cpu_set), &cpu_set); > ASSERT_OK(err, "set_thread_affinity"); > > - /* spin the loop for a while (random high number) */ > - for (i = 0; i < 1000000; ++i) > + for (i = 0; i < loops; ++i) { > ++j; > + barrier(); what's the rationale for barrier call in here, together with the volatile change above? thanks, jirka > + } > } > > static void pe_subtest(struct test_bpf_cookie *skel) > @@ -461,7 +464,7 @@ static void pe_subtest(struct test_bpf_cookie *skel) > attr.type = PERF_TYPE_SOFTWARE; > attr.config = PERF_COUNT_SW_CPU_CLOCK; > attr.sample_period = 100000; > - pfd = syscall(__NR_perf_event_open, &attr, -1, 0, -1, PERF_FLAG_FD_CLOEXEC); > + pfd = syscall(__NR_perf_event_open, &attr, 0, -1, -1, PERF_FLAG_FD_CLOEXEC); > if (!ASSERT_GE(pfd, 0, "perf_fd")) > goto cleanup; > > @@ -470,7 +473,7 @@ static void pe_subtest(struct test_bpf_cookie *skel) > if (!ASSERT_OK_PTR(link, "link1")) > goto cleanup; > > - burn_cpu(); /* trigger BPF prog */ > + burn_cpu(100000000L); /* trigger BPF prog */ > > ASSERT_EQ(skel->bss->pe_res, 0x100000, "pe_res1"); > > @@ -489,7 +492,7 @@ static void pe_subtest(struct test_bpf_cookie *skel) > if (!ASSERT_OK_PTR(link, "link2")) > goto cleanup; > > - burn_cpu(); /* trigger BPF prog */ > + burn_cpu(100000000L); /* trigger BPF prog */ > > ASSERT_EQ(skel->bss->pe_res, 0x200000, "pe_res2"); > > -- > 2.43.0 > >