linux-kernel - Re: Nested events with zero deltas, can use absolute timestamps instead?

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: <CAMmhGq+1gZvzR9RwJ6m1MzO1jnTy8yFx8jaRiWpGtZ=E6n9vig@mail.gmail.com>
Date:   Fri, 24 May 2019 08:11:12 -0700
From:   Jason Behmer <jbehmer@...gle.com>
To:     Steven Rostedt <rostedt@...dmis.org>
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, May 24, 2019 at 8:00 AM Steven Rostedt <rostedt@...dmis.org> wrote:
>
> 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

Ah, I was thinking of doing this within the existing timestamp_mode
config file.  Having a separate file does make it much less confusing.