[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150502063355.GA25303@gmail.com>
Date: Sat, 2 May 2015 08:33:55 +0200
From: Ingo Molnar <mingo@...nel.org>
To: Bartosz Golaszewski <bgolaszewski@...libre.com>
Cc: LKML <linux-kernel@...r.kernel.org>,
Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...hat.com>,
"H. Peter Anvin" <hpa@...or.com>, x86@...nel.org,
"Rafael J. Wysocki" <rjw@...ysocki.net>,
Viresh Kumar <viresh.kumar@...aro.org>,
Guenter Roeck <linux@...ck-us.net>,
Jean Delvare <jdelvare@...e.de>,
Fenghua Yu <fenghua.yu@...el.com>,
Benoit Cousson <bcousson@...libre.com>,
Peter Zijlstra <a.p.zijlstra@...llo.nl>
Subject: Re: [PATCH 5/6] x86: replace cpu_**_mask() with topology_**_cpumask()
* Bartosz Golaszewski <bgolaszewski@...libre.com> wrote:
> The former duplicate the functionalities of the latter but are neither
> documented nor arch-independent.
> if (!has_mp) {
> - cpumask_set_cpu(cpu, cpu_sibling_mask(cpu));
> + cpumask_set_cpu(cpu, topology_thread_cpumask(cpu));
> cpumask_set_cpu(cpu, cpu_llc_shared_mask(cpu));
So why does topology.h invent a new name for 'sibling CPUs'?
At least in the scheduling context, 'sibling' is the term we are using
in most places in the scheduler - try 'git grep sibling kernel/sched/'.
'thread' is a bad name anyway for a CPU, even if we didn't have an
existing term for it.
So please rename topology_thread_cpumask to topology_sibling_cpumask
to not replace one inconsistency for another one ...
Thanks,
Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists