mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@osdl.org>
To: Ashok Raj <ashok.raj@intel.com>
Cc: linux-kernel@vger.kernel.org, zwane@arm.linux.org.uk,
	vatsa@in.ibm.com, discuss@x86-64.org, rusty@rustycorp.com.au,
	ashok.raj@intel.com
Subject: Re: [patch 2/5] try2: x86_64: CPU hotplug support.
Date: Mon, 6 Jun 2005 15:11:56 -0700	[thread overview]
Message-ID: <20050606151156.7b26167f.akpm@osdl.org> (raw)
In-Reply-To: <20050606192113.044405000@araj-em64t>

Ashok Raj <ashok.raj@intel.com> wrote:
>
> Experimental CPU hotplug patch for x86_64

What does "experimental" mean?

>  static int __cpuinit do_boot_cpu(int cpu, int apicid)
>  {
> -	struct task_struct *idle;
>  	unsigned long boot_error;
>  	int timeout;
>  	unsigned long start_rip;
> -	/*
> -	 * We can't use kernel_thread since we must avoid to
> -	 * reschedule the child.
> -	 */
> -	idle = fork_idle(cpu);
> -	if (IS_ERR(idle)) {
> +	struct create_idle c_idle = {
> +		.cpu = cpu,
> +		.done = COMPLETION_INITIALIZER(c_idle.done),
> +	};
> +	DECLARE_WORK(work, do_fork_idle, &c_idle);
> +
> +	c_idle.idle = get_idle_for_cpu(cpu);
> +
> +	if (c_idle.idle) {
> +		c_idle.idle->thread.rsp = (unsigned long) (((struct pt_regs *)
> +			(THREAD_SIZE + (unsigned long) c_idle.idle->thread_info)) - 1);
> +		init_idle(c_idle.idle, cpu);
> +		goto do_rest;
> +	}
> +
> +	if (!keventd_up() || current_is_keventd())
> +		work.func(work.data);
> +	else {
> +		schedule_work(&work);
> +		wait_for_completion(&c_idle.done);
> +	}

This shouldn't be diddling with workqueue internals.  Why is this code
here?  If the workqueue API is inadequate then we should prefer to extend
it rather than working around any shortcoming.

> +		Dprintk ("do_boot_cpu %d Already started\n", cpu);

Please try to adopt a consistent coding style.

Using printk("%s", __FUNCTION__); is preferred, as it will still work if
someone later refactors this code into a new function.  (It can increase
code size.  Or decrease it if the string gets shared.  But that's moot if
the code is inside a normally-disabled macro like Dprintk.  Whatever that
is.)

> +static void
> +remove_siblinginfo(int cpu)

Unneeded newline here.

> +/* We don't actually take CPU down, just spin without interrupts. */
> +static inline void play_dead(void)
> +{
> +	idle_task_exit();
> +	mb();
> +	/* Ack it */
> +	__get_cpu_var(cpu_state) = CPU_DEAD;
> +
> +	while (1)
> +		safe_halt();
> +}

The memory barrier needs a comment, please.  It is otherwise not possible
to determine why it is there.

>  asmlinkage void default_do_nmi(struct pt_regs *regs)
>  {
>  	unsigned char reason = 0;
> +	int cpu;
> +
> +	cpu = smp_processor_id();
>  
>  	/* Only the BSP gets external NMIs from the system.  */
> -	if (!smp_processor_id())
> +	if (!cpu)
>  		reason = get_nmi_reason();
>  
> +	if (!cpu_online(cpu))
> +		return;
> +

Why would an offlined CPU receive an NMI?  (A comment would be handy)



  reply	other threads:[~2005-06-06 22:16 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-06-06 19:14 [patch 0/5] x86_64: try2: CPU hotplug patch series Ashok Raj
2005-06-06 19:14 ` [patch 1/5] try2: x86_64: Change init sections for CPU hotplug support Ashok Raj
2005-06-06 19:14 ` [patch 2/5] try2: x86_64: " Ashok Raj
2005-06-06 22:11   ` Andrew Morton [this message]
2005-06-06 22:43     ` Ashok Raj
2005-06-06 19:14 ` [patch 3/5] try2: x86_64: CPU hotplug sibling map cleanup Ashok Raj
2005-06-06 19:14 ` [patch 4/5] try2: x86_64: Dont use broadcast shortcut to make it cpu hotplug safe Ashok Raj
2005-06-06 22:13   ` Andrew Morton
2005-06-07  7:13   ` Shaohua Li
2005-06-07 12:05     ` Ashok Raj
2005-06-07 15:40     ` Ashok Raj
2005-06-06 19:14 ` [patch 5/5] try2: x86_64: Provide ability to choose using shortcuts for IPI in flat mode Ashok Raj
2005-06-06 22:14   ` Andrew Morton

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=20050606151156.7b26167f.akpm@osdl.org \
    --to=akpm@osdl.org \
    --cc=ashok.raj@intel.com \
    --cc=discuss@x86-64.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rusty@rustycorp.com.au \
    --cc=vatsa@in.ibm.com \
    --cc=zwane@arm.linux.org.uk \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®