* 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).