Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1340594 > unrolled thread

Re: [PATCH 4/4] tracing: Add __print_ns_to_secs() and __print_ns_without_secs() helpers

Started byPeter Zijlstra <peterz@infradead.org>
First post2016-02-23 13:50 +0100
Last post2016-02-23 15:40 +0100
Articles 4 — 2 participants

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.


Contents

  Re: [PATCH 4/4] tracing: Add __print_ns_to_secs() and  __print_ns_without_secs() helpers Peter Zijlstra <peterz@infradead.org> - 2016-02-23 13:50 +0100
    Re: [PATCH 4/4] tracing: Add __print_ns_to_secs() and  __print_ns_without_secs() helpers Steven Rostedt <rostedt@goodmis.org> - 2016-02-23 14:20 +0100
      Re: [PATCH 4/4] tracing: Add __print_ns_to_secs() and  __print_ns_without_secs() helpers Peter Zijlstra <peterz@infradead.org> - 2016-02-23 15:10 +0100
        Re: [PATCH 4/4] tracing: Add __print_ns_to_secs() and  __print_ns_without_secs() helpers Steven Rostedt <rostedt@goodmis.org> - 2016-02-23 15:40 +0100

#1340594 — Re: [PATCH 4/4] tracing: Add __print_ns_to_secs() and __print_ns_without_secs() helpers

FromPeter Zijlstra <peterz@infradead.org>
Date2016-02-23 13:50 +0100
SubjectRe: [PATCH 4/4] tracing: Add __print_ns_to_secs() and __print_ns_without_secs() helpers
Message-ID<r5kzE-5tk-15@gated-at.bofh.it>
On Mon, Feb 22, 2016 at 04:26:53PM -0500, Steven Rostedt wrote:
> From: "Steven Rostedt (Red Hat)" <rostedt@goodmis.org>
> 
> To have nanosecond output displayed in a more human readable format, its
> nicer to convert it to a seconds format (XXX.YYYYYYYYY). The problem is that
> to do so, the numbers must be divided by NSEC_PER_SEC, and moded too. But as
> these numbers are 64 bit, this can not be done simply with '/' and '%'
> operators, but must use do_div() instead.

Would not div_[us]64_rem() make more sense? It would typically result in
just the one division, instead of two.

[toc] | [next] | [standalone]


#1340597

FromSteven Rostedt <rostedt@goodmis.org>
Date2016-02-23 14:20 +0100
Message-ID<r5l2G-5VT-7@gated-at.bofh.it>
In reply to#1340594
On Tue, 23 Feb 2016 13:49:15 +0100
Peter Zijlstra <peterz@infradead.org> wrote:

> On Mon, Feb 22, 2016 at 04:26:53PM -0500, Steven Rostedt wrote:
> > From: "Steven Rostedt (Red Hat)" <rostedt@goodmis.org>
> > 
> > To have nanosecond output displayed in a more human readable format, its
> > nicer to convert it to a seconds format (XXX.YYYYYYYYY). The problem is that
> > to do so, the numbers must be divided by NSEC_PER_SEC, and moded too. But as
> > these numbers are 64 bit, this can not be done simply with '/' and '%'
> > operators, but must use do_div() instead.  
> 
> Would not div_[us]64_rem() make more sense? It would typically result in
> just the one division, instead of two.

The problem is, how do you do that in a printf() statement?

We have "%llu.%09ul" which is two arguments in the printf(). And the
values we are processing can't be modified. Which is why the macro uses
({ }) and creates a temp variable.

-- Steve

[toc] | [prev] | [next] | [standalone]


#1340655

FromPeter Zijlstra <peterz@infradead.org>
Date2016-02-23 15:10 +0100
Message-ID<r5lP5-6xC-25@gated-at.bofh.it>
In reply to#1340597
On Tue, Feb 23, 2016 at 08:17:57AM -0500, Steven Rostedt wrote:
> On Tue, 23 Feb 2016 13:49:15 +0100
> Peter Zijlstra <peterz@infradead.org> wrote:
> 
> > On Mon, Feb 22, 2016 at 04:26:53PM -0500, Steven Rostedt wrote:
> > > From: "Steven Rostedt (Red Hat)" <rostedt@goodmis.org>
> > > 
> > > To have nanosecond output displayed in a more human readable format, its
> > > nicer to convert it to a seconds format (XXX.YYYYYYYYY). The problem is that
> > > to do so, the numbers must be divided by NSEC_PER_SEC, and moded too. But as
> > > these numbers are 64 bit, this can not be done simply with '/' and '%'
> > > operators, but must use do_div() instead.  
> > 
> > Would not div_[us]64_rem() make more sense? It would typically result in
> > just the one division, instead of two.
> 
> The problem is, how do you do that in a printf() statement?
> 
> We have "%llu.%09ul" which is two arguments in the printf(). And the
> values we are processing can't be modified. Which is why the macro uses
> ({ }) and creates a temp variable.

Hurm,. yes that's not something easily done. We need a temporary limited
in scope to the printf statement, and C doesn't really do that.

[toc] | [prev] | [next] | [standalone]


#1340710

FromSteven Rostedt <rostedt@goodmis.org>
Date2016-02-23 15:40 +0100
Message-ID<r5mi7-6Kg-53@gated-at.bofh.it>
In reply to#1340655
On Tue, 23 Feb 2016 15:01:43 +0100
Peter Zijlstra <peterz@infradead.org> wrote:


> > We have "%llu.%09ul" which is two arguments in the printf(). And the
> > values we are processing can't be modified. Which is why the macro uses
> > ({ }) and creates a temp variable.  
> 
> Hurm,. yes that's not something easily done. We need a temporary limited
> in scope to the printf statement, and C doesn't really do that.

The nice thing is, the division is done on output, which is considered
the slow path. Having two divisions instead of just one may be
inconvenient, but it's not slowing much down. And that's only performed
when reading the ASCII trace files. If you use perf or trace-cmd, the
event-parser will do the work for you at post processing.

-- Steve

[toc] | [prev] | [standalone]


Back to top | Article view | linux.kernel


csiph-web