On Thu, 14 Nov 2019 23:24:28 -0500
"Frank A. Cancio Bello" [off-list ref] wrote:

On Thu, Nov 14, 2019 at 04:36:39PM -0500, Steven Rostedt wrote:

quoted

On Thu, 14 Nov 2019 15:20:59 -0500
Joel Fernandes [off-list ref] wrote:
  

quoted

On Wed, Nov 13, 2019 at 11:37:30AM -0500, Steven Rostedt wrote:  

quoted

On Wed, 13 Nov 2019 11:32:36 -0500
"Frank A. Cancio Bello" [off-list ref] wrote:    

[snip]  

quoted

quoted

+
+        The number of pages allocated for each CPU buffer may not
+        be the same than the round up of the division:
+        buffer_size_kb / PAGE_SIZE. This is because part of each page is
+        used to store a page header with metadata. E.g. with
+        buffer_size_kb=4096 (kilobytes), a PAGE_SIZE=4096 bytes and a
+        BUF_PAGE_HDR_SIZE=16 bytes (BUF_PAGE_HDR_SIZE is the size of the
+        page header with metadata) the number of pages allocated for each
+        CPU buffer is 1029, not 1024. The formula for calculating the
+        number of pages allocated for each CPU buffer is the round up of:
+        buffer_size_kb / (PAGE_SIZE - BUF_PAGE_HDR_SIZE).    

I have no problem with this patch, but the concern of documenting the
implementation here, which will most likely not be updated if the
implementation is ever changed, which is why I was vague to begin with.

But it may never be changed as that code has been like that for a
decade now.    

Agreed. To give some context, Frank is an outreachy intern I am working with and
one of his starter tasks was to understand the ring buffer's basics.  I asked
him to send a patch since I thought he mentioned there was an error in the
documnentation. It looks like all that was missing is some explanation which
the deleted text in brackets above should already cover.
  

Not exactly in my opinion ;) The deleted text was not the problem. I
just deleted it because with the added text it turns to be redundant.

The issue that I found with the documentation (maybe just to my
newbie's eyes) is in this part:

"The trace buffers are allocated in pages (blocks of memory that the
kernel uses for allocation, usually 4 KB in size). If the last page
allocated has room for more bytes than requested, the rest of the
page will be used, making the actual allocation bigger than requested
or shown."

For me that "suggests" the interpretation that the number of pages
allocated in the current implementation correspond with the round
integer division of buffer_size_kb / PAGE_SIZE, which is inaccurate
(for 5 pages in the example that I mentioned).

If you would like, you could reword that to something more accurate,
but still not detailing the implementation.

Understood and agreed. It is funny that what I spotted as "a problem"
was precisely an incomplete description of the implementation (the
sentences that I quoted above). What do you think about removing
those two sentences?

I wouldn't remove them, just reword them to something you find more
accurate.

-- Steve