linux-kernel - Re: [PATCH 1/6] sched_ext: idle: Extend topology optimizations to all tasks

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <Z9muBqNbDOxXMB-y@slm.duckdns.org>
Date: Tue, 18 Mar 2025 07:31:50 -1000
From: Tejun Heo <tj@...nel.org>
To: Andrea Righi <arighi@...dia.com>
Cc: David Vernet <void@...ifault.com>, Changwoo Min <changwoo@...lia.com>,
	Joel Fernandes <joelagnelf@...dia.com>, bpf@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/6] sched_ext: idle: Extend topology optimizations to
 all tasks

Hello,

On Tue, Mar 18, 2025 at 08:31:29AM +0100, Andrea Righi wrote:
> On Mon, Mar 17, 2025 at 08:22:35AM -1000, Tejun Heo wrote:
> ...
> > > +	/*
> > > +	 * If the task is allowed to run on all CPUs, simply use the
> > > +	 * architecture's cpumask directly. Otherwise, compute the
> > > +	 * intersection of the architecture's cpumask and the task's
> > > +	 * allowed cpumask.
> > > +	 */
> > > +	if (!cpus || p->nr_cpus_allowed >= num_possible_cpus() ||
> > > +	    cpumask_subset(cpus, p->cpus_ptr))
> > > +		return cpus;
> > > +
> > > +	if (!cpumask_equal(cpus, p->cpus_ptr) &&
> > 
> > Hmm... isn't this covered by the preceding cpumask_subset() test? Here, cpus
> > is not a subset of p->cpus_ptr, so how can it be the same as p->cpus_ptr?
> > 
> > > +	    cpumask_and(local_cpus, cpus, p->cpus_ptr))
> > > +		return local_cpus;
> > > +
> > > +	return NULL;
> 
> Also, I'm also wondering if there's really a benefit checking for
> cpumask_subset() and then doing cpumask_and() only when it's needed, or if
> we should just do cpumask_and(). It's true that we can save some writes,
> but they're done on a temporary local per-CPU cpumask, so they shouldn't
> introduce cache contention.

Yeah, I can imagine it going either way, so no strong preference.

Thanks.

-- 
tejun