From: Deepak Chitriki <deepak.chitriki@ti.com>
To: Ohad Ben-Cohen <ohad@wizery.com>
Cc: "Guzman Lugo, Fernando" <fernando.lugo@ti.com>,
"Ramirez Luna, Omar" <omar.ramirez@ti.com>,
"Kanigeri, Hari" <h-kanigeri2@ti.com>,
"linux-omap@vger.kernel.org" <linux-omap@vger.kernel.org>,
Hiroshi Doyu <Hiroshi.DOYU@nokia.com>
Subject: Re: [PATCH v3 4/4] omap: mailbox: convert block api to kfifo
Date: Mon, 7 Jun 2010 18:27:58 -0500 [thread overview]
Message-ID: <4C0D807E.2080607@ti.com> (raw)
In-Reply-To: <AANLkTik8tLfUzLxcd9tfC_VIgLcRGXbZPLM06nMsMHKz@mail.gmail.com>
Ohad Ben-Cohen wrote:
> Hi Deepak,
>
> On Mon, Jun 7, 2010 at 1:52 PM, Deepak Chitriki <deepak.chitriki@ti.com> wrote:
>
>> With this patch I observed "inconsistent lock state" warning.
>>
>
> Thanks for the report!
>
>
>> Kfifo is acccessed in omap_mbox_msg_send() and mbox_tx_tasklet()
>> functions.In order to protect this critical section we need to protect by
>> using spin_lock_bh() so that the tasklet cannot preempt
>> omap_mobx_msg_send().
>>
>
> This is actually not the problem: it's ok if mbox_tx_tasklet preempts
> omap_mbox_msg_send. In fact, such a use case is even ok if we don't
> take a spinlock at all: kfifo is designed in a way that if you have
> only 1 consumer and 1 producer, they can both access kfifo
> simultaneously without any locking. That's why we don't take the
> spinlock in the mbox_tx_tasklet. The reason, btw, that we take a
> spinlock in omap_mbox_msg_send is to allow multiple simultaneous
> sending contexts (taking a spinlock there ensures serialization of
> those multiple simultaneous sending contexts).
>
> The problem here lies in the fact (that I've just learnt) that
> dspbridge also sends mbox messages from a tasklet context
> (dpc_tasklet). Lockdep identifies that the spinlock is taken in a
> softirq context (dspbridge's dpc_tasklet) after it was previously
> taken in a softirq-enabled context. Your proposed fix will solve the
> lockdep issue here, but:
>
> Do we really want to have tasklets in dspbridge ? Are we that
> performance critical ?
>
> In general I'd prefer to switch to workqueues in both dspbridge and
> mailbox. I'm really not convinced we have to use tasklets in those
> modules, and workqueues are much more system friendly. This way we
> would also not have to stop all bottom halves when sending a mailbox
> message.
>
> Somewhat relevant note about mailbox performance: omap_mbox_msg_send
> often (i.e. when the kfifo is empty) can just send the message
> directly, without triggering the tasklet to do that. Applying such a
> change will substantially improve the mailbox performance, and will
> make the shift to workqueues even more reasonable. I've got a patch
> for that, I'll post it soon.
>
tasklet is run in atomic context,so I wonder how mailbox performance
will increase if you switch from tasklet to workqueue?
> What do you think (looping in Fernando, Omar and Hari) ?
>
> Thanks,
> Ohad.
>
next prev parent reply other threads:[~2010-06-07 23:28 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-05-05 15:33 [PATCH v3 0/4] omap: mailbox: cleanup & simplify Ohad Ben-Cohen
2010-05-05 15:33 ` [PATCH v3 1/4] omap: mailbox: convert rwlocks to spinlock Ohad Ben-Cohen
2010-05-05 15:33 ` [PATCH v3 2/4] omap: mailbox cleanup: split MODULE_AUTHOR line Ohad Ben-Cohen
2010-05-05 15:33 ` [PATCH v3 3/4] omap: mailbox: remove (un)likely macros from cold paths Ohad Ben-Cohen
2010-05-05 15:33 ` [PATCH v3 4/4] omap: mailbox: convert block api to kfifo Ohad Ben-Cohen
2010-06-07 18:52 ` Deepak Chitriki
2010-06-07 21:40 ` Ohad Ben-Cohen
2010-06-07 23:14 ` Guzman Lugo, Fernando
2010-06-08 2:54 ` Ohad Ben-Cohen
2010-06-09 5:07 ` Hiroshi DOYU
2010-06-09 5:16 ` Guzman Lugo, Fernando
2010-06-13 23:52 ` Ohad Ben-Cohen
2010-06-14 8:58 ` Hiroshi DOYU
2010-06-14 15:56 ` C.A, Subramaniam
2010-06-15 4:48 ` Ohad Ben-Cohen
2010-06-15 7:04 ` Hiroshi DOYU
2010-06-14 17:44 ` Sapiens, Rene
2010-06-14 17:47 ` Felipe Contreras
2010-06-15 4:43 ` Ohad Ben-Cohen
2010-06-15 8:04 ` Hiroshi DOYU
2010-06-16 5:09 ` Ohad Ben-Cohen
2010-06-16 5:50 ` Hiroshi DOYU
2010-06-23 0:29 ` Ohad Ben-Cohen
2010-07-02 12:08 ` Hiroshi DOYU
2010-06-08 3:46 ` Hiroshi DOYU
2010-06-08 9:43 ` Felipe Contreras
2010-06-08 9:55 ` Hiroshi DOYU
2010-06-08 18:49 ` Guzman Lugo, Fernando
2010-06-07 23:27 ` Deepak Chitriki [this message]
2010-06-08 3:11 ` Ohad Ben-Cohen
2010-06-08 3:55 ` Hiroshi DOYU
2010-06-08 9:51 ` Felipe Contreras
2010-06-08 3:40 ` Hiroshi DOYU
2010-06-08 17:02 ` Guzman Lugo, Fernando
2010-05-06 5:20 ` [PATCH v3 0/4] omap: mailbox: cleanup & simplify Hiroshi DOYU
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4C0D807E.2080607@ti.com \
--to=deepak.chitriki@ti.com \
--cc=Hiroshi.DOYU@nokia.com \
--cc=fernando.lugo@ti.com \
--cc=h-kanigeri2@ti.com \
--cc=linux-omap@vger.kernel.org \
--cc=ohad@wizery.com \
--cc=omar.ramirez@ti.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).