On Mon, 1 Apr 2019 06:49:07 -0700 Jason Behmer <jbeh...@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
