LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
* Correct commit mask for page data size
@ 2019-04-01 13:49 Jason Behmer
  2019-05-24  2:54 ` Steven Rostedt
  0 siblings, 1 reply; 3+ messages in thread
From: Jason Behmer @ 2019-04-01 13:49 UTC (permalink / raw)
  To: rostedt; +Cc: Craig Barabas, linux-kernel

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.

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.

Could you provide some guidance?

Thanks,
Jason

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Correct commit mask for page data size
  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
  0 siblings, 1 reply; 3+ messages in thread
From: Steven Rostedt @ 2019-05-24  2:54 UTC (permalink / raw)
  To: Jason Behmer; +Cc: Craig Barabas, linux-kernel

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


^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Correct commit mask for page data size
  2019-05-24  2:54 ` Steven Rostedt
@ 2019-05-24 14:04   ` Jason Behmer
  0 siblings, 0 replies; 3+ messages in thread
From: Jason Behmer @ 2019-05-24 14:04 UTC (permalink / raw)
  To: Steven Rostedt; +Cc: Craig Barabas, linux-kernel

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
>

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2019-05-24 14:04 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
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 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).