Michael Buesch wrote:
On Tuesday 27 June 2006 16:11, Jeff Garzik wrote:
Overall, bcm43xx is _really really bad_ about this sort of thing. Just
grepping for udelay in bcm43xx_radio.c shows some of the worst
offenders. bcm43xx_radio_init2060() and bcm43xx_radio_selectchannel()
both look like candidates for using msleep() rather than udelay().
This is _all_ at initialization time.
select_channel.... How often do you select a channel?
That question is irrelevant, because you have no idea what -else- is
going on in the system, at the point when bcm43xx chooses to spin the
CPU heavily.
Initialization time means you are definitely not in a hot path, and can
therefore sleep.
I recently reworked the periodically exectuted workhandlers,
so that they are preemptible.
Major classes of users run their kernels without preempt. Please don't
depend on that to avoid bad behavior.
mac_suspend():
It is always called in atomic context with IRQs disabled.
We need to wait for the device here to signal "OK, MAC is down
now and you can count on it". This takes a few usecs. I guess
it sends out all queued packets, or whatever. We don't know
really.
I can actually measure how long it takes, if you really desire
it.
We _need_ to wait there. It is something like synchronize_irq(), or
whatever. It is a synchronizing function and we need it to be
synchronizing.
And I don't think it is worth the pain to insert a preemption
point there (or doing even fancier things with workqueues and
completions).
Overall, I don't think bcm43xx is still so bad at
wasting CPU. Maybe we should still insert some voluntary
preemption points, if the bcm43xx user does not run a fully
preemptible kernel. But if a fully preemptible kernel is run,
I think it is all OK.
Never assume a preemptible kernel will clean up problems for you :)
Jeff
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
