转发：

转发：

[程�I俊]

[-- Attachment #1: Type: text/plain, Size: 1947 bytes --]

Spam detection software, running on the system "blaine.gmane.org",
has identified this incoming email as possible spam.  The original
message has been attached to this so you can view it or label
similar future email.  If you have any questions, see
@@CONTACT_ADDRESS@@ for details.

Content preview:  Ϊʲôҵ¼¨×ܸú²»ÉÏ£¬ÊDz»¹»Å¬Á¦Â𣿠¸½¼þÁ½Ììѧϰ½²ÎªÄú½â¾ö£¡
   Linux-nvdimm mailing list Linux-nvdimm-hn68Rpc1hR1g9hUCZPvPmw@public.gmane.org https://lists.01.org/mailman/listinfo/linux-nvdimm
   [...] 

Content analysis details:   (6.0 points, 5.0 required)

 pts rule name              description
---- ---------------------- --------------------------------------------------
 1.3 RCVD_IN_BL_SPAMCOP_NET RBL: Received via a relay in bl.spamcop.net
                 [Blocked - see <http://www.spamcop.net/bl.shtml?58.50.68.52>]
-0.0 RCVD_IN_DNSWL_NONE     RBL: Sender listed at http://www.dnswl.org/, no
                            trust
                            [198.145.21.10 listed in list.dnswl.org]
 0.0 T_HEADER_FROM_DIFFERENT_DOMAINS From and EnvelopeFrom 2nd level mail
                            domains are different
-0.6 RP_MATCHES_RCVD        Envelope sender domain matches handover relay domain
 2.4 DATE_IN_FUTURE_Q_PLUS  Date: is over 4 months after Received: date
-1.9 BAYES_00               BODY: Bayes spam probability is 0 to 1%
                            [score: 0.0000]
 0.1 RCVD_IN_SBL            RBL: Received via a relay in Spamhaus SBL
                            [58.50.68.52 listed in zen.spamhaus.org]
 2.6 MSOE_MID_WRONG_CASE    No description available.
 1.9 FORGED_MUA_OUTLOOK     Forged mail pretending to be from MS Outlook

The original message was not completely plain text, and may be unsafe to
open with some email clients; in particular, it may contain a virus,
or confirm that your address can receive spam.  If you wish to view
it, it may be safer to save it to a file and open it with an editor.


[-- Attachment #2: original message before SpamAssassin --]
[-- Type: message/rfc822, Size: 3054 bytes --]

[-- Attachment #2.1.1: Type: text/plain, Size: 62 bytes --]


Ϊʲôҵ¼¨×ܸú²»ÉÏ£¬ÊDz»¹»Å¬Á¦Âð£¿

¸½¼þÁ½Ììѧϰ½²ÎªÄú½â¾ö£¡

[-- Attachment #2.1.2: Type: text/plain, Size: 178 bytes --]

_______________________________________________
Linux-nvdimm mailing list
Linux-nvdimm-hn68Rpc1hR1g9hUCZPvPmw@public.gmane.org
https://lists.01.org/mailman/listinfo/linux-nvdimm

转发:

[Caine Chen]

Hi guys:
We found that some IRQ threads will block in local_bh_disable( ) for
long time in some situation and we hope to get your valuable suggestions.
My kernel version is 5.4 and the irq-delay is caused by the use of
write_lock_bh().
It can be described in the following figure:
(1) Thread_1 which is a SCHED_NORMAL thread runs on CPU1,
    and it uses read_lock_bh() to protect some data.
(2) Thread_2 which is a SCHED_RR thread runs on CPU1 and it preempts thread_1
    after thread_1 invoked read_lock_bh(). Thread_2 may run 60 ms in my system.
(3) Thread_3 which is a SCHED_NORMAL thread runs on CPU0. This thread acquires
    writer's lock by invoking write_lock_bh(). This function will disable
    button-half firstly by invoking local_bh_disable( ). But it will block in
    rt_write_lock() , because read lock is held by thread_1.
(4) At this time, if irq thread without IRQF_NO_THREAD flag on CPU0 trys to
    acquire bh_lock(it has been renamed as softirq_ctrl.lock now), irq
    thread will block because this lock is held by thread_3.

------------------------------------------------------------------------------------------------------------------------------------
CPU1                                                                            CPU0
-------------------------------------------------                    ---------------------------------------------------------------
thread_2                       thread_1                           thread_3                               irq_thread
--------------                  -----------                           -----------                            --------------
                                 read_lock_bh()

......
                                                                     write_lock_bh()
/*do work*/                                                                                               /* irq thread block here*/
                                                                                                              local_bh_disable()
......
                                 read_unlock_bh()
                                                                     ......
                                                                     /* do work */
                                                                     ......
                                                                     write_unlock_bh()
                                                                                                              irq_thread_fn()
----------------------------------------------------------------------------------------------------------------------------------

In this case, if SCHED_RR thread_2 preempts thread_1 and runs too much time, all
irq threads on CPU0 will be blocked.
It looks like a priority reverse problem of real-time thread preempt.
How can I avoid this problem?  I have a few thoughts:
(1) The key point, I think, is that write_lock_bh()/read_lock_bh() will disable
    buttom half which will disable some irq threads too. Could I use
    write_lock_irq()/read_lock_irq() instead?
(2) If my irq handler wants to get better performance, I should request a
    threaded handler for the IRQ as Sebastian suggested in LKML
    <RE: irq thread latency caused by softirq_ctrl.lock contention>.
    Is threaded handler designed for low irq delay?
(3) Thread_2 takes too long time for running. So it is not suitable to set this
    thread with high rt-priority. Should I reduce this thread's priority to
    solve this problem?

Are there better ways to avoid this problem? We hope to get your valuable
suggestions. Thanks!

Best regards,
Caine.chen
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.

此电子邮件及附件所包含内容具有机密性，且仅限于接收人使用。未经允许，禁止第三人阅读、复制或传播该电子邮件中的任何信息。如果您不属于以上电子邮件的目标接收者，请您立即通知发送人并删除原电子邮件及其相关的附件。

Re:

[Daniel Vacek]

Hi Caine,

On Tue, Jan 18, 2022 at 4:44 AM Caine Chen <caine.chen@dji.com> wrote:
>
> Hi guys:
> We found that some IRQ threads will block in local_bh_disable( ) for
> long time in some situation and we hope to get your valuable suggestions.
> My kernel version is 5.4 and the irq-delay is caused by the use of
> write_lock_bh().
> It can be described in the following figure:
> (1) Thread_1 which is a SCHED_NORMAL thread runs on CPU1,
>     and it uses read_lock_bh() to protect some data.
> (2) Thread_2 which is a SCHED_RR thread runs on CPU1 and it preempts thread_1
>     after thread_1 invoked read_lock_bh(). Thread_2 may run 60 ms in my system.
> (3) Thread_3 which is a SCHED_NORMAL thread runs on CPU0. This thread acquires
>     writer's lock by invoking write_lock_bh(). This function will disable
>     button-half firstly by invoking local_bh_disable( ). But it will block in
>     rt_write_lock() , because read lock is held by thread_1.
> (4) At this time, if irq thread without IRQF_NO_THREAD flag on CPU0 trys to
>     acquire bh_lock(it has been renamed as softirq_ctrl.lock now), irq
>     thread will block because this lock is held by thread_3.
>
> ------------------------------------------------------------------------------------------------------------------------------------
> CPU1                                                                            CPU0
> -------------------------------------------------                    ---------------------------------------------------------------
> thread_2                       thread_1                           thread_3                               irq_thread
> --------------                  -----------                           -----------                            --------------
>                                  read_lock_bh()
>
> ......
>                                                                      write_lock_bh()
> /*do work*/                                                                                               /* irq thread block here*/
>                                                                                                               local_bh_disable()
> ......
>                                  read_unlock_bh()
>                                                                      ......
>                                                                      /* do work */
>                                                                      ......
>                                                                      write_unlock_bh()
>                                                                                                               irq_thread_fn()
> ----------------------------------------------------------------------------------------------------------------------------------
>
> In this case, if SCHED_RR thread_2 preempts thread_1 and runs too much time, all
> irq threads on CPU0 will be blocked.
> It looks like a priority reverse problem of real-time thread preempt.

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...).

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

> How can I avoid this problem?  I have a few thoughts:
> (1) The key point, I think, is that write_lock_bh()/read_lock_bh() will disable
>     buttom half which will disable some irq threads too. Could I use
>     write_lock_irq()/read_lock_irq() instead?
> (2) If my irq handler wants to get better performance, I should request a
>     threaded handler for the IRQ as Sebastian suggested in LKML
>     <RE: irq thread latency caused by softirq_ctrl.lock contention>.
>     Is threaded handler designed for low irq delay?
> (3) Thread_2 takes too long time for running. So it is not suitable to set this
>     thread with high rt-priority. Should I reduce this thread's priority to
>     solve this problem?
>
> Are there better ways to avoid this problem? We hope to get your valuable
> suggestions. Thanks!
>
> Best regards,
> Caine.chen
> 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.
>
> 此电子邮件及附件所包含内容具有机密性，且仅限于接收人使用。未经允许，禁止第三人阅读、复制或传播该电子邮件中的任何信息。如果您不属于以上电子邮件的目标接收者，请您立即通知发送人并删除原电子邮件及其相关的附件。