RE: [PATCH 1/6]sep initializing rework

["Protasevich, Natalie" <Natalie.Protasevich@UNISYS.com>]

Hello,
This is a hotplug CPU patch for i386, done against 2.6.12-rc2-mm3.
Somewhat alternative to the one posted by Li Shaohua, but not really
(and I didn't mean that :). If you look closer, our patches are
different and can complement each other I think. Li did great job on
sep, after-offline cleanup, __devinit etc., and I have some radical
changes in the AP bringup mechanism. I left alone __init to __devinit
part (I was going through it lately, but I think even though I had few
more than Li did, he covered it sufficiently perhaps). I started having
doubts in free_initmem() vs __devinit because look how many of __init's
left! just a few :). I got rid of do_boot_cpu loop in smpboot.c because
the loop
static void __init smp_init(void)
{
        unsigned int i;

        /* FIXME: This should be done in userspace --RR */
        for_each_present_cpu(i) {
                if (num_online_cpus() >= max_cpus)
                        break;
                if (!cpu_online(i))
                        cpu_up(i);
        }
...
does it again so why leave it in smpboot.c to boot AP's twice. I also
found that my system fails sooner or later when I try not to synch
runtime booted processor with others, so I changed tsc synchronization
to only sync between booting CPU and the one that boots it. The patch
works for me on Intel 8x generic box, and on ES7000. I was asked to
separate my patch into smaller ones by the theme, but I'm posting the
entire patch for now, because I think it is probably not the final one.
I think (I hope) I will sync up with Li later on.
My idea was that if we find a CPU core in ACPI (enabled or disabled), we
encounter for it in sibling map and create a sysfs node accordingly, and
cpu_possible_map will reflect that. We take processors up/down depending
on physical presence using the existing node. That's the scenario
implemented on ES7000 that reports all possible cores in ACPI marking
absent processors as disabled. Runtime enablement/disablement depends on
sysfs only and the driving agent can be anything (ACPI or user) that
triggers sysfs node for this processor.
Thanks,
--Natalie

-----Original Message-----
From: Zwane Mwaikambo [mailto:zwane@arm.linux.org.uk] 
Sent: Tuesday, April 12, 2005 6:08 AM
To: Li Shaohua
Cc: lkml; ACPI-DEV; Len Brown; Pavel Machek; Andrew Morton; Protasevich,
Natalie; Ryan Harper
Subject: Re: [PATCH 1/6]sep initializing rework

Hello Shaohua,

On Tue, 12 Apr 2005, Li Shaohua wrote:

> These patches (together with 5 patches followed this one) are updated 
> suspend/resume SMP patches. The patches fixed some bugs and do clean 
> up as suggested. Now they work for both suspend-to-ram and
suspend-to-disk.
> Patches are against 2.6.12-rc2-mm3.

These patches look good and i think we should go ahead with them. I've
also cross checked with physical hotplug cpu patches for ES7xxx from
Natalie (added to Cc) and it does indeed look like a lot of the code
will work for her too, but i'd appreciate it if she also does a double
check. 
Obviously this won't work for other upcoming users of hotplug cpu like
Xen (Ryan added to Cc) but i think we can abstract things later on to
cover other special users.

Thanks Shaohua,
	Zwane

Attachment: hotcpu-2.6.11.diff
Description: hotcpu-2.6.11.diff