Hi Daniel:
Thanks for your reply.
> Not really. I guess there's one misunderstanding in your description.
> Disabling the bottom half is local to running thread and not to the
> CPU which executes that thread. As an effect, preemption practically
> enables the bottom half again (as long as the new thread did not have
> it already disabled before, of course...).
It's a bit confused for me why disabling the bottom half is local to thread
and not to the CPU. From my humble perspective, every forced threaded
irq_threads will invoke local_bh_disable( ) and try to get bh_lock before they
enter irq handler. If bh_lock(now is softirq_ctrl.lock) is held by other thread,
all forced-threaded irq_threads on this CPU will wait until the lock is released.
So how does preemption enable the bottom half again?
To test this, I did an experiment in v5.4 kernel.
First, I created a kthread and bound it to CPU0:
int test_init( )
{
......
p = kthread_create(my_debug_func, NULL, "my_test");
kthread_bind(p, 0);
wake_up_process(p);
......
}
This kthread will invoke local_bh_disable()/local_bh_enable() periodically:
int my_debug_func(void *arg)
{
......
while(!kthread_should_stop()) {
......
local_bh_disable();
/* just do some busy work, such as memcpy, kmalloc and so on */
do_some_work();
local_bh_enable();
}
......
}
What'more, I added some logs in some forced-threaded irq handlers to find out when they was excuted.
After "my_test" thread disabled local bh, there were no forced-threaded irq threads running on CPU0.
But after "my_test" thread enabled local bh, forced-threaded irqs came again.
It seems that disabling the bottom half is local to CPU.
> That said, the irq_thread will _not_ be blocked as bottom half is not
> disabled in it's context. From your chart, it's disabled only in
> thread_3 context and thread_1 context. But these two are independent
> (due to the different thread contexts and not the different CPU
> contexts as you misassumed) and they do not block each other either,
> it's the rw_lock serializing these threads, right?
> You should be able to see this with tracing. There should be no issue
> or the issue is different than you think it is and different than you
> described here.
> Hopefully the above helps you,
> Daniel
Thanks
Caine
This email and any attachments thereto may contain private, confidential, and privileged material for the sole use of the intended recipient. Any review, copying, or distribution of this email (or any attachments thereto) by others is strictly prohibited. If you are not the intended recipient, please contact the sender immediately and permanently delete the original and any copies of this email and any attachments thereto.
此电子邮件及附件所包含内容具有机密性，且仅限于接收人使用。未经允许，禁止第三人阅读、复制或传播该电子邮件中的任何信息。如果您不属于以上电子邮件的目标接收者，请您立即通知发送人并删除原电子邮件及其相关的附件。
