Re: CPU attachent and detachment in a running Linux system

[Heiko.Carstens@de.ibm.com]

>> 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/