On Thu, 26 Apr 2007 18:28:38 +0530
Gautham R Shenoy <[email protected]> wrote:
> I just checked with Vatsa if there was any subtle reason why they
> had put in the kthread_bind() in cpu.c. Vatsa cannot seem to recollect
> any and I can't see any. So let us just remove the kthread_bind.
>
> Signed-off-by: Gautham R Shenoy <[email protected]>
> ---
> kernel/cpu.c | 4 ----
> 1 files changed, 4 deletions(-)
>
> Index: linux-2.6.21-rc7/kernel/cpu.c
> ===================================================================
> --- linux-2.6.21-rc7.orig/kernel/cpu.c
> +++ linux-2.6.21-rc7/kernel/cpu.c
> @@ -176,10 +176,6 @@ static int _cpu_down(unsigned int cpu, i
> /* This actually kills the CPU. */
> __cpu_die(cpu);
>
> - /* Move it here so it can run. */
> - kthread_bind(p, get_cpu());
> - put_cpu();
> -
> /* CPU is completely dead: tell everyone. Too late to complain. */
> if (raw_notifier_call_chain(&cpu_chain, CPU_DEAD | mod,
> hcpu) == NOTIFY_BAD)
So I cooked up a changelog and queued up the diff. But I have an uneasy
feeling that things are getting a bit close to guesswork here.
We have a huge amount of change pending in the kthread/workqueue/freezer
area, partly because I decided not to merge most of the workqueue changes
into 2.6.21.
It'd be good if people could take some time to sit down and re-review the
code which we presently have. I plan on sending it all off for 2.6.22 and
there might be some glitches but it seems to have a good track record so
far.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
