From: Michael Buesch <mb@bu3sch.de>
To: Oliver Hartkopp <socketcan@hartkopp.net>
Cc: "John W. Linville" <linville@tuxdriver.com>,
Kalle Valo <kalle.valo@iki.fi>,
linux-wireless@vger.kernel.org, netdev@vger.kernel.org,
Johannes Berg <johannes@sipsolutions.net>
Subject: Re: mac80211: NOHZ: local_softirq_pending 08
Date: Wed, 30 Sep 2009 16:33:02 +0200 [thread overview]
Message-ID: <200909301633.04376.mb@bu3sch.de> (raw)
In-Reply-To: <4AC3475C.7000403@hartkopp.net>
On Wednesday 30 September 2009 13:56:12 Oliver Hartkopp wrote:
> John W. Linville wrote:
> > On Sat, Sep 12, 2009 at 06:41:12PM +0200, Oliver Hartkopp wrote:
> >
> >> i cooked a patch that introduces netif_rx_ti() and fixes up the problems in
> >> mac80211 and the CAN subsystem.
> >
> > Oliver,
> >
> > Are you going to send this patch to Dave? If you want me to carry
> > it instead, please resend it with a proper changelog including a
> > Signed-off-by line. For that matter, Dave will most certainly want
> > that as well...
>
> Hello John,
>
> as i wrote here
>
> http://marc.info/?l=linux-netdev&m=125277885910179&w=2
>
> there are currently only three occurrences of checks that use netif_rx() and
> netif_rx_ni() depending on in_interrupt().
>
> And regarding the suggested fix from Michael, that checked every(!) netif_rx()
> whether it is in interrupt or not, i was unsure if a netif_tx_ti() would make
> sense for only three cases?!?
>
> If you think it makes sense, i can post a patch for that ... but:
>
> Indeed it costs some additional investigation to prove whether netif_rx() or
> netif_rx_ni() should be used in each case. But IMHO this has to be done before
> providing a pump-gun function that solves the problem without thinking if we
> are in irq-context or not. I want to avoid that people are using netif_rx_ti()
> as some kind of default ...
>
> I don't know how expensive in_interrupt() is, but it IMO should be avoided
> when the context for a code section can be determined in another way.
What if we just get the fix merged and discuss later whether it's worth to optimize a picosecond or not??
My patch fixes the _bug_. You can merge a more "efficient" fix later that saves one or two CPU cycles.
--
Greetings, Michael.
next prev parent reply other threads:[~2009-09-30 14:33 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-09-11 14:48 mac80211: NOHZ: local_softirq_pending 08 Michael Buesch
2009-09-11 14:57 ` Kalle Valo
2009-09-11 15:07 ` Michael Buesch
2009-09-11 16:07 ` Kalle Valo
2009-09-11 16:07 ` Oliver Hartkopp
2009-09-11 16:13 ` Michael Buesch
2009-09-12 16:41 ` Oliver Hartkopp
2009-09-12 16:51 ` Michael Buesch
2009-09-12 18:07 ` Oliver Hartkopp
2009-09-29 19:29 ` John W. Linville
2009-09-30 11:56 ` Oliver Hartkopp
2009-09-30 14:33 ` Michael Buesch [this message]
2009-09-30 14:47 ` Kalle Valo
2009-09-30 14:54 ` Johannes Berg
2009-09-30 15:10 ` Michael Buesch
2009-09-30 15:21 ` Johannes Berg
2009-09-30 17:51 ` Oliver Hartkopp
2009-09-30 18:18 ` [PATCH] net: fix " Oliver Hartkopp
2009-09-30 18:47 ` John W. Linville
2009-09-30 23:33 ` David Miller
2009-10-01 7:08 ` Oliver Hartkopp
2009-10-01 14:04 ` Michael Buesch
2009-10-01 14:24 ` Kalle Valo
2009-10-01 18:42 ` Johannes Berg
2009-10-01 19:10 ` Michael Buesch
2009-10-01 19:26 ` Johannes Berg
2009-10-01 19:32 ` David Miller
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=200909301633.04376.mb@bu3sch.de \
--to=mb@bu3sch.de \
--cc=johannes@sipsolutions.net \
--cc=kalle.valo@iki.fi \
--cc=linux-wireless@vger.kernel.org \
--cc=linville@tuxdriver.com \
--cc=netdev@vger.kernel.org \
--cc=socketcan@hartkopp.net \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.