lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190524110048.142efd44@gandalf.local.home>
Date:   Fri, 24 May 2019 11:00:48 -0400
From:   Steven Rostedt <rostedt@...dmis.org>
To:     Jason Behmer <jbehmer@...gle.com>
Cc:     tom.zanussi@...ux.intel.com, linux-kernel@...r.kernel.org
Subject: Re: Nested events with zero deltas, can use absolute timestamps
 instead?

On Fri, 24 May 2019 07:17:15 -0700
Jason Behmer <jbehmer@...gle.com> wrote:


> Hi Steven,
> Your other email reminded me of this thread.  The easy "fix" we
> decided to pursue was to simply turn on absolute timestamps for all
> events and use up the extra space, which in our particular application
> isn't a huge deal.  We haven't yet gotten around to trying to send a
> patch for plumbing user-configurable absolute timestamps, but as noted
> immediately above, the configuration for timestamp_mode is actually a
> bit tricky to implement with the existing histogram ref counting.  The
> way I was thinking about dealing with that was to have a separate bool
> to indicate the state the user has indicated they want, and then you
> have to work through all the possible combinations of behavior:
> 
> If user absolute timestamps is false, all behavior is exactly as today.
> If user absolute timestamps is true, histogram refs transitioning 0->1
> is a no-op, as is histogram refs transitioning 1->0.
> If histogram refs are 0 and user absolute timestamps transition
> false->true or true->false, they get what they want.
> If histogram refs are >0 and user absolute timestamps transition
> false->true, it's a no-op.
> 
> And the confusing one:
> If histogram refs are >0 and user absolute timestamps transitions
> true->false we can't turn off absolute timestamps and screw up the
> histograms, so we return an error.  But user absolute timestamps is
> now false, which means when histogram refs transitions back to 0, it
> will turn off absolute timestamps.
> 
> What do you think of that?

I don't think that's confusing if its well documented. Have the user
flag called "force_absolute_timestamps", that way it's not something
that the user will think that we wont have absolute timestamps if it is
zero. Have the documentation say:

 Various utilities within the tracing system require that the ring
 buffer uses absolute timestamps. But you may force the ring buffer to
 always use it, which will give you unique timings with nested tracing
 at the cost of more usage in the ring buffer.

-- Steve

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ