[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH] CPU: abstract read-mostly-ness for per-CPU cpumask_var_t variables
- To: Jan Beulich <jbeulich@xxxxxxxx>
- From: Roger Pau Monné <roger.pau@xxxxxxxxxx>
- Date: Mon, 2 Feb 2026 16:50:34 +0100
- Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com; dkim=pass header.d=citrix.com; arc=none
- Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=v+RRRC0MOrEnYrxIii09KIC60Ite75AJyfTqgG+qhec=; b=RaGQSUuWFdo3cJnb57ydR5bqGXZ4ZsZr/9ZsHktIkYWw2kk0j0NT1nna1YOs+wfJlLz6vskJWiaxMgNVk3GlYs3WHIl90QM48koJMbU0ntVH5hT6ROQjnkfDnGOBiAhrqt9z//DZnVMUQCsvaxbzLeHfZG0GFeUXDIEkcf7c4dLXdtXWMfYBepl1DH5EsAzKrhv9C5rATxwj7gB/RNksaVhmY2OS9haAKW+atBINe7sYeqqh5BIJfoZOjEcFo+a4tRtZWKrNvdOETcwBaGe/DbPt9TaDE5K4fh6IIwiTRwmW1PjJS0e9oe9QOX05HAAVQsL/1Ll69XmPLgHwXF8b8g==
- Arc-seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=C6mgCZu5bGPBqIa9ALF4mmiLPODJ2/bSTHliSIYEcG+0qyPd2A9BYR4h0T3cWxEH1XDiys04azBbWEF5uAOxiSiAtXcuzSr6rKI7sXFf10mGACJ5mcLjbC5O92hEx5ivj4OvfC9k20breSzA5YnsJeQmPkU8rtLzC1oHFs+uXbAkHm7FsA7/f00USwmQm55fr3Yctgxv1QwY+MDx7gd5EhrPFuUWREyjaVDptpkzExlVnAV6j0Df32fNipH2z0qcTARkWef76z/FauaR5PXmqkGLd8wJloaP0PNuPghsNLd58Fn0T2hWuNrUU9naFgwhtl673AICAfMKPx19W7qUqA==
- Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com;
- Cc: "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, Julien Grall <julien@xxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, Anthony PERARD <anthony.perard@xxxxxxxxxx>, Michal Orzel <michal.orzel@xxxxxxx>
- Delivery-date: Mon, 02 Feb 2026 15:50:50 +0000
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
On Wed, Nov 12, 2025 at 04:53:27PM +0100, Jan Beulich wrote:
> cpumask_var_t can resolve to a pointer or to an array. While the pointer
> typically is allocated once for a CPU and then only read (i.e. wants to be
> marked read-mostly), the same isn't necessarily true for the array case.
> There things depend on how the variable is actually used. cpu_core_mask
> and cpu_sibling_mask (which all architectures have inherited from x86,
> which in turn is possibly wrong) are altered only as CPUs are brought up
> or down, so may remain uniformly read-mostly. Other (x86-only) instances
> want to change, to avoid disturbing adjacent read-mostly data.
>
> While doing the x86 adjustment, also do one in the opposite direction,
> i.e. where there was no read-mostly annotation when it is applicable in
> the "pointer" case.
>
> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
Acked-by: Roger Pau Monné <roger.pau@xxxxxxxxxx>
> ---
> Really in the pointer case it would be nice if the allocations could then
> also come from "read-mostly" space.
Hm, I guess for some of them yes, it would make sense to come from
__read_mostly space, but would require passing an extra parameter to
the DEFINE_ helper? Or introduce another variant.
Thanks, Roger.
|
