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
20 matches
Mail list logo
