On Wed July 21 2010 16:53:21 Johannes Berg wrote:
> On Wed, 2010-07-21 at 14:17 +0900, Bruno Randolf wrote:
> > but that's for all tracepoints all over the kernel...
>
> Well you definitely don't want to enable like function graph tracing,
> that's expected to be more expensive unless you also hav
On Wed, 2010-07-21 at 14:17 +0900, Bruno Randolf wrote:
> but that's for all tracepoints all over the kernel...
Well you definitely don't want to enable like function graph tracing,
that's expected to be more expensive unless you also have the callsite
patching version of it. But _just_ enabling
On Wed, 21 Jul 2010 14:17:23 +0900, Bruno Randolf wrote:
> but that's for all tracepoints all over the kernel... i think it's natural
> that this takes some CPU time. note that on these boards even the 22Mbps are
> limited by the CPU processing power.
>
The key word here is some. The numbers th
On Wed July 21 2010 12:41:50 Bob Copeland wrote:
> On Wed, Jul 21, 2010 at 10:04:59AM +0900, Bruno Randolf wrote:
> > the difference. without tracing you can get 22Mbps, with tracing max
> > 15Mbps UDP thruput.
>
> If so, and it's not an i-cache effect, then something is wrong with
> the tracing s
On Wed, Jul 21, 2010 at 10:04:59AM +0900, Bruno Randolf wrote:
> the difference. without tracing you can get 22Mbps, with tracing max 15Mbps
> UDP thruput.
If so, and it's not an i-cache effect, then something is wrong with
the tracing subsystem. It's supposed to compile to something like
if (t
On Tue, Jul 20, 2010 at 06:04:59PM -0700, Bruno Randolf wrote:
> On Tue July 20 2010 23:52:00 Bob Copeland wrote:
> > > again, here my same concerns: printing the reasons for resets is
> > > something which is useful on embedded boards and production setups which
> > > can't have tracing enabled. w
On Tue July 20 2010 23:52:00 Bob Copeland wrote:
> > again, here my same concerns: printing the reasons for resets is
> > something which is useful on embedded boards and production setups which
> > can't have tracing enabled. which is why i want to object against this
> > change!
>
> What Johanne
On Tue, Jul 20, 2010 at 02:20:49PM +0900, Bruno Randolf wrote:
> > @@ -931,6 +930,7 @@ ath5k_debug_printrxbuf(struct ath5k_buf *bf, int done,
> > void
> > ath5k_debug_printrxbuffs(struct ath5k_softc *sc, struct ath5k_hw *ah)
> > {
> > +#if 0
(The above, by the way, is a mistake I'll fix; I forg
On Sun July 18 2010 04:35:36 Bob Copeland wrote:
> This change adds a tracepoint for ath5k_reset. We record the
> reason for each reset and the new channel frequency.
>
> Signed-off-by: Bob Copeland
> ---
> drivers/net/wireless/ath/ath5k/ath5k_trace.h | 38 +
> drivers/net/wir
This change adds a tracepoint for ath5k_reset. We record the
reason for each reset and the new channel frequency.
Signed-off-by: Bob Copeland
---
drivers/net/wireless/ath/ath5k/ath5k_trace.h | 38 +
drivers/net/wireless/ath/ath5k/base.c| 56 +++---
10 matches
Mail list logo
