From: Jason Behmer <jbehmer@google.com>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: Craig Barabas <craigbarabas@google.com>, linux-kernel@vger.kernel.org
Subject: Re: Correct commit mask for page data size
Date: Fri, 24 May 2019 07:04:11 -0700 [thread overview]
Message-ID: <CAMmhGqJVmoiWmQ67B4FMEk_n1cf0Gk4ugjg2-C6MVo033upF2w@mail.gmail.com> (raw)
In-Reply-To: <20190523225423.372ef0b0@oasis.local.home>
Yup, that makes sense, thanks for the response.
On Thu, May 23, 2019 at 7:54 PM Steven Rostedt <rostedt@goodmis.org> wrote:
>
> On Mon, 1 Apr 2019 06:49:07 -0700
> Jason Behmer <jbehmer@google.com> wrote:
>
> Hi Jason,
>
> I just noticed this email. I know it's a late response, but since you
> Cc'd LKML, I figured I would respond anyway, and at least have an
> answer in the archives ;-)
>
> > Hi Steven,
> > We're wondering what the correct number of bits to take from the
> > commit field is when determining the size of the page data. The
> > format file shows the bottom 56 bits not overlapping with anything:
> >
> > field: local_t commit; offset:8; size:8; signed:1;
> > field: int overwrite; offset:8; size:1; signed:1;
> >
> > We first naively interpreted this as the size, but eventually ran into
> > cases where this gave back a nonsense result. But then in our
> > investigation of what the correct thing to do is, we found conflicting
> > answers.
>
> Yeah, I hated that above, but the format didn't have a good way to show
> the overwrite without breaking existing tools :-/
>
> >
> > In the kernel we see that commit is often updated to write, which is
> > masked against RB_WRITE_MASK. So it seems taking the bottom 20 bits
> > is correct. However, in trace-cmd, a fairly authoritative parser, we
> > see that COMMIT_MASK is set to take the bottom 27 bits and set that to
> > the page data size.
>
> The way the kernel uses that number is that the first 20 bits are the
> size. Then we have an internal counter (top 12 bits) used for
> synchronizing when the trace crosses pages. But these internal numbers
> will never be exposed when it is sent off to the reader. Hence, those
> bits are meaningless.
>
> Now I probably could make the trace-cmd header just use those 20 bits,
> as they never will be used for the size. When I wrote that, I just made
> sure that the flags that are added to the page by the reader code was
> not set. Which is why there is a discrepancy between the two masks.
> >
> > Could you provide some guidance?
>
> Thanks for pointing this out. Again, the reason for the difference is
> that they were created from two different perspectives. One was that it
> would use the top 12 bytes for internal purposes, the other was just to
> allow for up to 5 flags by the reader.
>
> Does that make sense?
>
> -- Steve
>
prev parent reply other threads:[~2019-05-24 14:04 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-04-01 13:49 Correct commit mask for page data size Jason Behmer
2019-05-24 2:54 ` Steven Rostedt
2019-05-24 14:04 ` Jason Behmer [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAMmhGqJVmoiWmQ67B4FMEk_n1cf0Gk4ugjg2-C6MVo033upF2w@mail.gmail.com \
--to=jbehmer@google.com \
--cc=craigbarabas@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=rostedt@goodmis.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).