From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f45.google.com (mail-wm1-f45.google.com [209.85.128.45]) (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 240B5329373 for ; Fri, 22 May 2026 16:08:21 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.45 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779466103; cv=none; b=Vh4StNqnzvrxDBb53HRdmoMtC6dFX8/8hFPk1nX/ic6LUMk/0mSqyeolIo+OUz6cs6SgHNOiwDH18/NRgeNAa+58vir3rgyPIARG4UPmskmj7kMqPVtbDAsK5GqBvCZCbjs4ewLAHf3JDGojZCXJ7K103t1a7dcydEiVZ8/1wpw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779466103; c=relaxed/simple; bh=dgFcTwwHgZbu0ShW/XSgzvTFCf4IH5Whe+IwGXcKHms=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=pxonubraMgoM2D0oTVi4zv/DBtWrv8cFvGq7r7TsrPypyAFEJ/059fb1EKKjpNEwNO6wUKoUIWjsOZGoOVgc3i4f6oeiN1/d7yctxJzJt+AhmbRIp0I6Hf6Ut8NHzm4dnGziv/oVE6++liP2jB6UhG5Z6NYmjMhVJXIYMkrpqww= 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=cE6EXJ2P; arc=none smtp.client-ip=209.85.128.45 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="cE6EXJ2P" Received: by mail-wm1-f45.google.com with SMTP id 5b1f17b1804b1-48984d29fe3so78521255e9.0 for ; Fri, 22 May 2026 09:08:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1779466100; x=1780070900; 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=rU23XY7n5jv5JNpVtXVCjODWXeYBfaDkDfjvBRX0m2E=; b=cE6EXJ2PEAg4xWCzw1HCiJDSF8xOkbqcD02oTFs1uIM7gu5ADynhqED6NXfNQcK18u 9qMsG1BJoZdbm4orpYXa8Xv1q7XaJuCVYKYqvuArjZMvCi0IgGgsmorrHEu8oW0G/fel i2shnJbRsv4ulzf4pxf7NvSSJyCivOd4bIW1+m9w9/B1KI9xGvGlqMexNwSWExDQim9s 386BA+uhyVF8ApQ8INumz141rCtDj7xavFTEqdqA2utk7sX1KKuOTbPc/ClVkd/dVun3 IbIJaQDMYSv8tL4ZIcQT9ceRHuQS0CUxNU4wYdrJnzy9nnEZ20zrXrYjZtwtFEYqdlKB wF4w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1779466100; x=1780070900; 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=rU23XY7n5jv5JNpVtXVCjODWXeYBfaDkDfjvBRX0m2E=; b=qKVfZ2+MK/m9yEv4mq9DInI9gTy0e3JntbVUv0JQdscNAu2FQBDlGbPgX21zo3SKgK RXvPEf/kwYkuUieS4TRqguXljdjBhC94szSTwOebi+yxxjwFHULK2bpBiA92mCA4YHkp fkOMTzvzcJrSsUK6Z5z7KLNgrynxTodF2iTdaA1GZGDtrp1k9MAs8vRWNfsO1E7BN8FL RVXos+mnYp7NR4Lkou7+IgJDyHvfoyIMb+AhBNfBcvdPjh+Dfks4cfKHqdZ9tRvhxtho n5jJNkdJnkdEC1OIsTL4lYEIGE34uxy+NjKGaipQWDJZshydbfkpUU4hG1cDO//tE14l 5Z5Q== X-Forwarded-Encrypted: i=1; AFNElJ8y6hnW6VrDbHA3ofSziUL0yh3HyQTekOp8/ZGEoHpSrGscLAeKN47Z5yJU1O2zLILeTBdQKGiUCFDRRAU=@vger.kernel.org X-Gm-Message-State: AOJu0Yz3p0zsA+6h1gt2F7nMDONeHtoVi9g/2QSckGKSX1iZ1D9/5aOs 9K6NFAd4TOPzdpd6HyVFFj6xfqKEvK+JmRt3sG1o6/+7nDUie5rCCBXThmvXUHiTBHg= X-Gm-Gg: Acq92OEhokF6IdRFWorg2f78m7WApba8olneiVvR8GoRas7huYclT8WtEjcXa1ioAyT KIhhZICPLlYUkz2Z4LYsauEEUfvEsV+oUd81tQjtm3wHM1s3cdotLiuzLVHGKgMW+jiMQXA75nY sV3y6BGTW0xNOB0TPPUHCCCnYx34eQAuIXGDoFaO+QZlz9dAZW/QOKI4+2h5SVhy5iJCSCncmd4 Sn/QTF3oGuDtTWxGGL7KLYqaepYhdhFHOlpdRuVQAx1IMZC1rKBhZ2EzkGjI22oAO9u/xoZRQCc O/53G/90SujHCcsEJM/q1KbzWS9i9dFj8a1yhiM4M42rIyC8SCAWiW4BtunzJRbA1sHoULTRwhE CFcsH7Idv5ui+fJPE3NQQepXn4GVPg4DwUbNpruQWcoVvDCz4MHHzWJCD0o0yWwCKD3wlFuAGpW NhxSk60kgXTsguIi/LptsNE3foeEANWp3owZphyEqCUtKOF0Cgj0ZVSnQ/Vu0= X-Received: by 2002:a05:600c:8a0a:20b0:490:3ec9:8711 with SMTP id 5b1f17b1804b1-490426cda2amr46625325e9.18.1779466100500; Fri, 22 May 2026 09:08:20 -0700 (PDT) Received: from localhost.localdomain (nat2.prg.suse.com. [195.250.132.146]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-490469f61b0sm13807065e9.5.2026.05.22.09.08.19 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 22 May 2026 09:08:19 -0700 (PDT) Date: Fri, 22 May 2026 18:08:18 +0200 From: Michal =?utf-8?Q?Koutn=C3=BD?= To: Thomas Falcon Cc: Tejun Heo , Johannes Weiner , cgroups@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [RFC PATCH] cgroup/rstat: convert rstat lock from spinlock to rwlock Message-ID: References: <20260519173134.1486365-1-thomas.falcon@intel.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="ndjsbbbdcldyger7" Content-Disposition: inline In-Reply-To: <20260519173134.1486365-1-thomas.falcon@intel.com> --ndjsbbbdcldyger7 Content-Type: text/plain; protected-headers=v1; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Subject: Re: [RFC PATCH] cgroup/rstat: convert rstat lock from spinlock to rwlock MIME-Version: 1.0 Hi Thomas. On Tue, May 19, 2026 at 12:31:34PM -0500, Thomas Falcon wrote: > @@ -414,7 +427,7 @@ __bpf_kfunc void css_rstat_flush(struct cgroup_subsys= _state *css) > struct cgroup_subsys_state *pos; > =20 > /* Reacquire for each CPU to avoid disabling IRQs too long */ > - __css_rstat_lock(css, cpu); > + __css_rstat_lock(css, cpu, true); > pos =3D css_rstat_updated_list(css, cpu); > for (; pos; pos =3D pos->rstat_flush_next) { > if (is_self) { > @@ -424,7 +437,7 @@ __bpf_kfunc void css_rstat_flush(struct cgroup_subsys= _state *css) > } else > pos->ss->css_rstat_flush(pos, cpu); > } > - __css_rstat_unlock(css, cpu); > + __css_rstat_unlock(css, cpu, true); > if (!cond_resched()) > cpu_relax(); > } > @@ -717,11 +730,11 @@ void cgroup_base_stat_cputime_show(struct seq_file = *seq) > =20 > if (cgroup_parent(cgrp)) { > css_rstat_flush(&cgrp->self); > - __css_rstat_lock(&cgrp->self, -1); > + __css_rstat_lock(&cgrp->self, -1, false); > bstat =3D cgrp->bstat; > cputime_adjust(&cgrp->bstat.cputime, &cgrp->prev_cputime, > &bstat.cputime.utime, &bstat.cputime.stime); > - __css_rstat_unlock(&cgrp->self, -1); > + __css_rstat_unlock(&cgrp->self, -1, false); I was wondering where these distinctions of readers vs writers stem from and here I see that it's mainly the per-subsys vs rstat_base_lock. Given that cputime_adjust() is here only modifying the local bstat value, the read-like lock makes sense. However, there's still the cgroup's flush right above which would take the per-subsys locks in write-mode anyway. Can you add some more explanation why this works? More generally, I'm wondering where are the opportunities for replacing per-subsys lock with an RW lock (or seqcount). Thanks for looking into cpu.stat scalability, Michal --ndjsbbbdcldyger7 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iJEEABYKADkWIQRCE24Fn/AcRjnLivR+PQLnlNv4CAUCahB/bhsUgAAAAAAEAA5t YW51MiwyLjUrMS4xMiwyLDIACgkQfj0C55Tb+Aj2vwD/XhOVsLGNHHeMHlUYshr3 5m/WFWsTx45yB2kgTvVqEpwBAKpWlMeU2J7pwzelKK7NyxLTvfcqZ9vZnDn2EDP6 FP8L =eRJj -----END PGP SIGNATURE----- --ndjsbbbdcldyger7--