[lkml]   [2019]   [Nov]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [RFC 1/2] docs: ftrace: Clarify the RAM impact of buffer_size_kb
On Wed, Nov 13, 2019 at 11:37:30AM -0500, Steven Rostedt wrote:
> On Wed, 13 Nov 2019 11:32:36 -0500
> "Frank A. Cancio Bello" <> wrote:
> > +
> > + 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.

Steve, your call if you want this patch. Looks like Frank understands the
page header taking up some space, so one of the goals of the exercise is
accomplished ;-)


- Joel

 \ /
  Last update: 2019-11-14 21:22    [W:0.096 / U:0.156 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site