All of lore.kernel.org
 help / color / mirror / Atom feed
From: mark.rutland@arm.com (Mark Rutland)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC 2/3] arm: make cpu a percpu variable
Date: Thu, 15 Mar 2018 18:06:12 +0000	[thread overview]
Message-ID: <20180315180612.vpae3c5k4msc2tz3@lakrids.cambridge.arm.com> (raw)
In-Reply-To: <20180315170859.93893-3-zsm@chromium.org>

On Thu, Mar 15, 2018 at 05:08:58PM +0000, Zubin Mithra wrote:
> Without CONFIG_THREAD_INFO_IN_TASK, core code maintains thread_info::cpu
> and arch specific code can use this to build raw_smp_processor_id().
> With CONFIG_THREAD_INFO_IN_TASK, core code maintains task_struct::cpu,
> and arch specific code cannot access this due to header file circular
> dependency.
> 
> Instead, we can maintain a percpu variable containing the cpu number.
> 
> This also means that cpu numbers obtained using smp_processor_id cannot
> be used to set_my_cpu_offset. Use task_cpu(current) instead to get the
> cpu in those cases.
> 
> Earlier raw_smp_processor_id() was current_thread_info()->cpu :-
> 	mov	r3, sp
> 	bic     r3, r3, #8128
> 	bic     r3, r3, #63
> 	ldr     r0, [r3, #16]
> 
> Now it is *raw_cpu_ptr(&cpu_number) :-
> 	movw	r3, #57344
> 	movt	r3, #32917
> 	mrc	15, 0, r0, cr13, cr0, {4}
> 	ldr	r0, [r3, r0]

It's probably worth noting that with the thread_info moved off of the
stack, were we to use that to get at the cpu number, this would require
a similar sequence to the raw_cpu_ptr() code here.

This might make more sense after a patch using a register for the
thread_info (which would also allow for having separate IRQ stacks).

> 
> Signed-off-by: Zubin Mithra <zsm@chromium.org>
> ---
>  arch/arm/include/asm/cputype.h | 3 +++
>  arch/arm/include/asm/smp.h     | 3 ++-
>  arch/arm/kernel/setup.c        | 2 +-
>  arch/arm/kernel/smp.c          | 5 +++--
>  arch/arm/kernel/topology.c     | 5 +++++
>  5 files changed, 14 insertions(+), 4 deletions(-)
> 
> diff --git a/arch/arm/include/asm/cputype.h b/arch/arm/include/asm/cputype.h
> index cb546425da8a..10148c7af12f 100644
> --- a/arch/arm/include/asm/cputype.h
> +++ b/arch/arm/include/asm/cputype.h
> @@ -2,6 +2,9 @@
>  #ifndef __ASM_ARM_CPUTYPE_H
>  #define __ASM_ARM_CPUTYPE_H
>  
> +#include <asm/percpu.h>
> +DECLARE_PER_CPU(int, cpu_number);
> +

Why isn't this defined in <asm/smp.h>, as we do on arm64?

> --- a/arch/arm/include/asm/smp.h
> +++ b/arch/arm/include/asm/smp.h
> @@ -18,7 +18,8 @@
>  # error "<asm/smp.h> included in non-SMP build"
>  #endif
>  
> -#define raw_smp_processor_id() (current_thread_info()->cpu)
> +#include <asm/cputype.h>
> +#define raw_smp_processor_id() (*raw_cpu_ptr(&cpu_number))

It might be worth dragging the comment along from arm64, explaining why
we must use *raw_cpu_ptr(), and not this_cpu_read(), etc.

> --- a/arch/arm/kernel/topology.c
> +++ b/arch/arm/kernel/topology.c
> @@ -30,6 +30,9 @@
>  #include <asm/cputype.h>
>  #include <asm/topology.h>
>  
> +DEFINE_PER_CPU_READ_MOSTLY(int, cpu_number);
> +EXPORT_PER_CPU_SYMBOL(cpu_number);

Why not in smp.c, as with arm64?

> +
>  /*
>   * cpu capacity scale management
>   */
> @@ -310,6 +313,8 @@ void __init init_cpu_topology(void)
>  	for_each_possible_cpu(cpu) {
>  		struct cputopo_arm *cpu_topo = &(cpu_topology[cpu]);
>  
> +		per_cpu(cpu_number, cpu) = cpu;

Likewise, why isn't this in smp_prepare_cpus() in smp.c?

This isn't toplogy related, so it would be better placed there.

Thanks,
Mark.

  reply	other threads:[~2018-03-15 18:06 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-03-15 17:08 [RFC 0/3] ARM: thread_info to task_struct Zubin Mithra
2018-03-15 17:08 ` [RFC 1/3] arm: factor out current_stack_pointer Zubin Mithra
2018-03-15 17:58   ` Mark Rutland
2018-03-15 17:08 ` [RFC 2/3] arm: make cpu a percpu variable Zubin Mithra
2018-03-15 18:06   ` Mark Rutland [this message]
2018-03-15 17:08 ` [RFC 3/3] arm: add refcounting for task stacks Zubin Mithra

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20180315180612.vpae3c5k4msc2tz3@lakrids.cambridge.arm.com \
    --to=mark.rutland@arm.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.