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 0196337E2E4 for ; Tue, 23 Jun 2026 13:52:34 +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=1782222757; cv=none; b=PORMEg20osniSrVzcMvicl6H4Px+T9a/iK0dlqaxKbklgvCAv4pGFiFF34zdSkk/mNiTr0vGQ4BTpULc2fgHv2CG70QuabLfoenhbE30jkjjbOr10mtoTFTeq6eyJOdyn24STaD++3Tfpyv5Q62Q3ZR1jqSwMKs1+qui/g1e2QQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782222757; c=relaxed/simple; bh=qQDzdCIM36hTAqOEAnWir+7wrUqqW1kd9jhGVeFV15I=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=maNUixzFyvZBxu9YZUHwRH18OAYcjLUR0htLRKP0gAAMrI2xQP7/TG3z7gk6kIyl+X/gmG5J0PwfHZId6JdI6cujzcYzHgOV1L3MbboUu+5bFI1GhVkGdupmEPKJMpOGyVeXZ+yP/G4c/XTPPVnZlXxaZwJvXHbXSssnYDtiWnY= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=suse.com; spf=pass smtp.mailfrom=suse.com; dkim=pass (2048-bit key) header.d=suse.com header.i=@suse.com header.b=ADOSpobz; arc=none smtp.client-ip=209.85.221.46 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=suse.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=suse.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=suse.com header.i=@suse.com header.b="ADOSpobz" Received: by mail-wr1-f46.google.com with SMTP id ffacd0b85a97d-4629d80fa08so5388151f8f.3 for ; Tue, 23 Jun 2026 06:52:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1782222753; x=1782827553; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=PHObhepawfnCQqRNz4R+JkWCcyuhA+vOquuYLNzbdAc=; b=ADOSpobzjcEHMkYS/sXIZQVl12XUJxZyCde6NbG569ry62GsvfZJQbNIabmCIXW0c6 WTjV7ynnXngK/dxEitSDCKJbdG7zjJv2XH1NLDpXqs2XZexUN0Q22p8Yx1FZXv/uoT9d T/ixCXEyGiH7t7+cr94+LJYCD6Xjp3vOAEgNXyrP2DfWeBwRa8BoRojdKIZJ0SALOY3V SLqj00yV936CMBQZecJ2hXJ9Sx/vC1Q21TWGjMYiQADpE8K7Ja7H+PwVlfLVOvJkMGN3 lpIKPP+H92mjgMti9Af3DKaF74AAGaxkFBqyaKGotAGSuknI1/YH6vk/y6vaY2xiSB+n nTNA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1782222753; x=1782827553; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=PHObhepawfnCQqRNz4R+JkWCcyuhA+vOquuYLNzbdAc=; b=PMl6FeljtzEgi2KgNPl5X83NplrmIMWtriakvhXpoqnUawAmRII9tSS6qcFRBjuxVz zDOlSQOlZWZ7kU8LYckHhpM+5+P4qMyWxEmN/5ZW8nPWFs1mQ9yhPuMXh7MqBed1mq2k AsO4WQIUZ4GfiRg3zMcibjsDM9kO3TlKjavQdrIeGTrZdqixsg9B7pez0TFV3Q0WawgG Km5RIFQO0naS56FjshvOTbBFmzt4HIc848m/YpO3PwPswVed7ogO75+S4uDB/h5FiS1Z lIN0Q3UWODiEI/6cNGCUpPZM50kQ0uro4OVIJNJQYN/PCqniEKV9wzJ95uwczUgP0U1V Cxkw== X-Forwarded-Encrypted: i=1; AFNElJ8JFrkOR1LaZrNLD4+vqgEFAZwqClDih7o+QTul5HmdrWJ/w4T320tGyiXypiMYDJ11ZcSJQfa3fXLvJaM=@vger.kernel.org X-Gm-Message-State: AOJu0YznLwNL+BAXZfC1eq9qSBfy7/WFM1eg/x9HHMJN4xJldu2SgQ31 UhkweZT3b1ka3uptO61lAQnY+u9vOBqOJczrYQpLRnj/VBB8Uzo+3FLnwHYJoD0pm1E= X-Gm-Gg: AfdE7cmPgDzmkuzVfEFwnhCeIdYsbRwZLcLtVopWpXTafG9GTz+ybNM7Li/HtYJMc/G Lw36va67B+pJyNeIogV/j+OwpeUK6gKRbrIRU870204g1Szzd4jI4ox5u//5dfb7ONio3i+k+1M Zmkd0eSuE6klXf7Z4wzJo+MnsyBuQn9FItSL5CarGZisTNc5IvGT1bdM45WCiK2HKVXToKdhk+z +NKoiKBOIZCsXQNxq1Z6skslqhnDtdm4p8slVGOc4yb0JlT3U091sz7bbFCPPB9ipnlSrv7A/au 1IcgDVUvr2ArQGiTjEU07IwWIFsNaLCeCWRZgXQbe3aO4empsiiLewjAAe+8/QSF+GNErE1F8pT oCZgxuLTynHRHp4lEkm6fThYQnor14vMYD75p/3VP0SS1sRqLkFwjp2sREb0aXdbqLwFD6M+gKt xE8kk/Rck8wf4cBP7+8Q== X-Received: by 2002:a05:600c:1d1e:b0:492:4ca9:a46d with SMTP id 5b1f17b1804b1-4924ca9a4e8mr212679495e9.5.1782222753308; Tue, 23 Jun 2026 06:52:33 -0700 (PDT) Received: from localhost.localdomain ([62.77.90.70]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4923fd15470sm438068605e9.2.2026.06.23.06.52.32 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 23 Jun 2026 06:52:32 -0700 (PDT) Date: Tue, 23 Jun 2026 15:52:30 +0200 From: Michal =?utf-8?Q?Koutn=C3=BD?= To: Joe Simmons-Talbott Cc: Tejun Heo , Johannes Weiner , Shuah Khan , cgroups@vger.kernel.org, linux-kselftest@vger.kernel.org, linux-kernel@vger.kernel.org, Sebastian Chlad Subject: Re: [PATCH v2] selftests/cgroup: Adjust cpu.max quota based on HZ Message-ID: References: <20260622194305.601392-1-joest@redhat.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="xyyzzujscooqtqev" Content-Disposition: inline In-Reply-To: <20260622194305.601392-1-joest@redhat.com> --xyyzzujscooqtqev Content-Type: text/plain; protected-headers=v1; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Subject: Re: [PATCH v2] selftests/cgroup: Adjust cpu.max quota based on HZ MIME-Version: 1.0 On Mon, Jun 22, 2026 at 03:43:04PM -0400, Joe Simmons-Talbott wrote: > +static long > +_get_config_hz(void) > +{ > + long hz =3D -1; > + FILE *f; > + char cmd[256] =3D "zcat /proc/config.gz 2>/dev/null | grep '^CONFIG_HZ= =3D'"; > + > + f =3D popen(cmd, "r"); > + > + if (!f) > + goto out; > + > + fscanf(f, "CONFIG_HZ=3D%ld", &hz); > + > +out: > + pclose(f); > + return hz; > +} I like that you voiced this dependency on CONFIG_HZ and also that _SC_CLK_TCK is useless in this regards. (I see that BPF selftests have similar infra for this.) > + > /* > * This test creates a cgroup with some maximum value within a period, a= nd > * verifies that a process in the cgroup is not overscheduled. > @@ -646,7 +669,8 @@ test_cpucg_nested_weight_underprovisioned(const char = *root) > static int test_cpucg_max(const char *root) > { > int ret =3D KSFT_FAIL; > - long quota_usec =3D 1000; > + long hz =3D _get_config_hz(); > + long quota_usec; > long default_period_usec =3D 100000; /* cpu.max's default period */ > long duration_seconds =3D 1; I would not bend the tested value but it's expectation (so that approximately same quantity is tested acroos configs). I reckon the problem might be tasks that overrun the quota due to long tick, fortunately, we can assume this is compensated over multiple periods, so _on average_ quota should be honored (more) precisely. But the test duration may be not well aligned with all the compensation periods, to that must be accounted for in the expectation. When I write it all down, I get this: --- a/tools/testing/selftests/cgroup/test_cpu.c +++ b/tools/testing/selftests/cgroup/test_cpu.c @@ -651,7 +651,9 @@ static int test_cpucg_max(const char *root) long duration_seconds =3D 1; long duration_usec =3D duration_seconds * USEC_PER_SEC; - long usage_usec, n_periods, remainder_usec, expected_usage_usec; + long usage_usec, expected_usage_usec; + long n_periods, spread_periods, unaligned; + long tick_usec, low_usage, high_usage; char *cpucg; char quota_buf[32]; @@ -687,9 +689,16 @@ static int test_cpucg_max(const char *root) * the cpu hog is set to run as per wall-clock time */ n_periods =3D duration_usec / default_period_usec; - remainder_usec =3D duration_usec - n_periods * default_period_usec; - expected_usage_usec - =3D n_periods * quota_usec + MIN(remainder_usec, quota_usec= ); + tick_usec =3D USEC_PER_SEC / hz; + /* Up to tick_usec (over)run is compensated over multiple periods */ + spread_periods =3D MAX(1, tick_usec / quota_usec); + low_usage =3D n_periods / spread_periods; + high_usage =3D (n_periods + spread_periods - 1) / spread_periods; + unaligned =3D n_periods % spread_periods; + + expected_usage_usec =3D quota_usec * ( + unaligned * high_usage + + (spread_periods - unaligned) * low_usage); if (!values_close_report(usage_usec, expected_usage_usec, 10)) goto cleanup; (I neglected (and dropped) remainder_usec because it is zero with default values) However, not all preemptions are tick-based, so there'd be noise=20 and one has to tune the values_clone_report(,,err) anyway. Then to reduce noise, the simpler solution is to let the test run longer duration_usec =3D duration_seconds * USEC_PER_SEC * 1000 / hz; (where 1000 is the CONFIG_HZ=3D1000 where the test runs sufficiently [1] we= ll.) Joe, how do to the two variants above (unalignment account and prolonged duration) affect test_cpu behavior on your setup? (I'm personally wondering what is bigger quantity: systemic error due to HZ quantization or random (SMP) error.) Thanks, Michal [1] Even there one runs into noise depending on nr_cpus, thus even that fixed err=3D10 is not ideal. --xyyzzujscooqtqev Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iJEEABYKADkWIQRCE24Fn/AcRjnLivR+PQLnlNv4CAUCajqPlBsUgAAAAAAEAA5t YW51MiwyLjUrMS4xMiwyLDIACgkQfj0C55Tb+AjYkwEAkanTs6Oe4Wq8RbfJGWwj wfOgF9zepsGbVUE/9eQ+9FkBAIPJFLYaGnMSkGMcL8dWTL+iRmaz7E8a+o4mmZjT mKEM =5cZS -----END PGP SIGNATURE----- --xyyzzujscooqtqev--