Messages in this thread |  | | From | Heiko.Carstens@de ... | Date | Tue, 12 Dec 2000 07:42:29 +0100 | Subject | Re: CPU attachent and detachment in a running Linux system |
| |
>> sigp. To synchronize n CPUs one can create n kernel threads and give >> them a high priority to make sure they will be executed soon (e.g. by >> setting p->policy to SCHED_RR and p->rt_priority to a very high >> value). As soon as all CPUs are in synchronized state (with >> interrupts disabled) the new CPU can be started. But before this can >> be done there are some other things left to do: > >You dont IMHO need to use such a large hammer. We already do similar sequences >for tlb invalidation on X86 for example. You can broadcast an interprocessor >interrupt and have the other processors set a flag each. You spin until they >are all captured, then when you clear the flag they all continue. You just >need to watch two processors doing it at the same time 8)
Alan,
thanks for your input but I think it won't work this way because the value of smp_num_cpus needs to be increased by one right before a new cpu gets started. Then one can imagine the following situation at one of the cpus that needs to be captured:
read the value of smp_num_cpus; - interrupt that is intended to capture this cpu - the value of smp_num_cpus will be increased and the new cpu will be started by another cpu before this cpu continues with normal operation; - end of interrupt handling - do something that relies on the prior read value of smp_num_cpus (which is now wrong);
The result would be an inconsistency. This problem should not occur if all cpus would be captured by kernel threads.
I still wonder what you and other people think about the idea of an interface where the parts of the kernel with per-cpu dependencies should register two functions...
Best regards, Heiko
By the way, I changed the subject of your original reply because I sent my first mail twice (with and without a subject line). I'm sorry for my own stupidity :)
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/
|  |