CPU attachent and detachment in a running Linux system
Quoted 4 lines
Quoted 8 lines
Quoted 6 lines
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->policytoSCHED_RRandp->rt_priorityto 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
Quoted 1 line
for tlb invalidation on X86 for example. You can broadcast an
interprocessor
Quoted 1 line
interrupt and have the other processors set a flag each. You spin until
they
Quoted 2 lines
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 [email protected]
Please read the FAQ at http://www.tux.org/lkml/
Quoted 4 lines
thanks for your input but I think it won't work this way because the value of
smp_num_cpusneeds 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:
This is fine providing the code is aware of the potential race. You capture all the CPUs up the count by one, set the new cpu going and wait for it to jump to being captured (even though not by an interrupt) ?
Quoted 3 lines
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...
The other approach would be too make sure the per CPU structures allocated which consume little memory have space already for the extra processors - eg with the arrays of pointers etc
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/
Hi!
Quoted 3 lines
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...
Why not compile kernel with structeres big enough for 32 processors, and then just add CPUs up to the limit without changing anything?
Pavel
Signature · 6 lines
I'm [email protected]. "In my country we have almost anarchy and I don't care." Panos Katsaloulis describing me w.r.t. patents at [email protected] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] Please read the FAQ at http://www.tux.org/lkml/