On Fri, 2013-07-26 at 15:45 +0200, Johannes Berg wrote:
> Well, right now I can live with allocation 110 bytes for each
> tracepoint, this would just optimise it down. If I was in the middle of
> writing one such event while an interrupt came in, I'd not be able to
> reduce the ring-buffer allocat
On Fri, 2013-07-26 at 09:17 -0400, Steven Rostedt wrote:
> On Fri, 2013-07-26 at 15:06 +0200, Johannes Berg wrote:
> > On Fri, 2013-07-26 at 08:28 -0400, Steven Rostedt wrote:
>
> > Ah, yes, that'd work. I was considering putting it into the trace event
> > handling itself so I don't have to alloc
On Fri, 2013-07-26 at 15:06 +0200, Johannes Berg wrote:
> On Fri, 2013-07-26 at 08:28 -0400, Steven Rostedt wrote:
> Ah, yes, that'd work. I was considering putting it into the trace event
> handling itself so I don't have to allocate those buffers and put the
> handling into every tracepoint, but
On Fri, 2013-07-26 at 08:28 -0400, Steven Rostedt wrote:
> > My original though here was that we should be able to reserve (maximum)
> > space on the per-CPU buffer, and then relinquish some of it after the
> > tracepoint was written to the data, but I never had the time to check if
> > that was p
On Fri, 2013-07-26 at 11:19 +0200, Johannes Berg wrote:
> My original though here was that we should be able to reserve (maximum)
> space on the per-CPU buffer, and then relinquish some of it after the
> tracepoint was written to the data, but I never had the time to check if
> that was possible t
On Thu, 2013-07-11 at 15:29 -0400, Steven Rostedt wrote:
> > Note that there's no easy way to dynamically allocate the right amount
> > of space in the ringbuffer, or at least I haven't found one. We
> > therefore have a static size, which is somewhat inefficient.
>
> Can you add a helper functio
[sorry for the late response!]
> Yes, that does look inefficient. Would it make sense to add a couple
> different trace event classes for different sized buffers, and call
> those trace classes conditionally, based on the size of the formatted
> string? Or would that be too much of a mess.
I do
On Fri, Jul 12, 2013 at 12:55:43PM -0400, Steven Rostedt wrote:
> On Fri, 2013-07-12 at 09:41 -0700, Sarah Sharp wrote:
> > On Fri, Jul 12, 2013 at 07:25:59AM +0300, Kalle Valo wrote:
>
> > Thanks for the suggestion. I'm not familiar with all the userspace
> > tools for trace events, so I didn't
* Mark Wielaard (m...@redhat.com) wrote:
> Hi Mathieu,
>
> On Fri, Jul 12, 2013 at 01:08:28PM -0400, Mathieu Desnoyers wrote:
> > * Sarah Sharp (sarah.a.sh...@linux.intel.com) wrote:
> > > Thanks for the suggestion. I'm not familiar with all the userspace
> > > tools for trace events, so I didn't
Hi Mathieu,
On Fri, Jul 12, 2013 at 01:08:28PM -0400, Mathieu Desnoyers wrote:
> * Sarah Sharp (sarah.a.sh...@linux.intel.com) wrote:
> > Thanks for the suggestion. I'm not familiar with all the userspace
> > tools for trace events, so I didn't know about the command parser. Is
> > there documen
Sarah Sharp writes:
> On Fri, Jul 12, 2013 at 07:25:59AM +0300, Kalle Valo wrote:
>
>> Instead of individual trace points for command I would recommend to
>> consider just pushing the whole command buffer to the trace point and
>> parse the command in trace-cmd plugin in user space. Kernel code w
* Sarah Sharp (sarah.a.sh...@linux.intel.com) wrote:
> On Fri, Jul 12, 2013 at 07:25:59AM +0300, Kalle Valo wrote:
> > Sarah Sharp writes:
> >
> > > My initial list of specific trace points was something like:
> > >
> > > 1. xHCI host initialization and shutdown
> > >
> > > 2. xHCI memory allocat
On Fri, 2013-07-12 at 09:41 -0700, Sarah Sharp wrote:
> On Fri, Jul 12, 2013 at 07:25:59AM +0300, Kalle Valo wrote:
> Thanks for the suggestion. I'm not familiar with all the userspace
> tools for trace events, so I didn't know about the command parser. Is
> there documentation or a list of reso
On Fri, Jul 12, 2013 at 07:25:59AM +0300, Kalle Valo wrote:
> Sarah Sharp writes:
>
> > My initial list of specific trace points was something like:
> >
> > 1. xHCI host initialization and shutdown
> >
> > 2. xHCI memory allocation (dynamic ring resizing, structure alloc, etc)
> >
> > 3. A few in
Sarah Sharp writes:
> My initial list of specific trace points was something like:
>
> 1. xHCI host initialization and shutdown
>
> 2. xHCI memory allocation (dynamic ring resizing, structure alloc, etc)
>
> 3. A few individual xHCI host controller command tracepoints:
>* status only for all
Johannes Berg writes:
>> (Mentors and wireless folks, we're struggling a bit with adding trace
>> events to the xHCI USB host controller driver. I'm trying to look at
>> the ath6kl driver trace events as an example. We could use some help
>> and/or advice.)
>
> Those were in turn modelled on ma
On Thu, 2013-07-11 at 19:08 +0200, Johannes Berg wrote:
> > > lets say that we want the tracepoint function to have the prototype:
> > >
> > > void trace_cmd_address_device(const char *fmt, ...).
>
> I'm not sure this is possible. I think we (wireless) do this with
>
> void trace_cmd_address_de
On Thu, Jul 11, 2013 at 07:08:53PM +0200, Johannes Berg wrote:
> [also adding Steven, he's the tracing expert after all :-)]
>
> Hi Xenia, Sarah, all,
>
> > (Mentors and wireless folks, we're struggling a bit with adding trace
> > events to the xHCI USB host controller driver. I'm trying to look
[also adding Steven, he's the tracing expert after all :-)]
Hi Xenia, Sarah, all,
> (Mentors and wireless folks, we're struggling a bit with adding trace
> events to the xHCI USB host controller driver. I'm trying to look at
> the ath6kl driver trace events as an example. We could use some help
On 07/11/2013 06:20 PM, Sarah Sharp wrote:
On Mon, Jul 08, 2013 at 09:17:59PM +0300, Xenia Ragiadakou wrote:
But when there are other function calls before the callback call, I don't
no why but i cannot track anymore the position of the args following the
fmt argumenent in the stack with the p
On Mon, Jul 08, 2013 at 09:17:59PM +0300, Xenia Ragiadakou wrote:
> Hi Sarah,
Hi Xenia,
Comments below.
(Mentors and wireless folks, we're struggling a bit with adding trace
events to the xHCI USB host controller driver. I'm trying to look at
the ath6kl driver trace events as an example. We co
21 matches
Mail list logo
