[PATCH v2] tracing: shrink max latency ringbuffer if unnecessary

[KOSAKI Motohiro]

> Hi Kosaki,
> 
> FYI, could you send emails to my goodmis account. I can easily miss
> emails sent to my RH account since it is usually flooded with RH
> Bugzilla reports.

Ahh sorry. yes, I had hear the same thing. I did forgot it.
I've fixed my adress book ;)

> 
> (more below)
> 
> On Wed, 2010-06-30 at 12:06 +0900, KOSAKI Motohiro wrote:
> > Documentation/trace/ftrace.txt says
> > 
> >   buffer_size_kb:
> > 
> >         This sets or displays the number of kilobytes each CPU
> >         buffer can hold. The tracer buffers are the same size
> >         for each CPU. The displayed number is the size of the
> >         CPU buffer and not total size of all buffers. 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.
> >         ( Note, the size may not be a multiple of the page size
> >           due to buffer management overhead. )
> > 
> >         This can only be updated when the current_tracer
> >         is set to "nop".
> > 
> > But it's incorrect. currently total memory consumption is
> > 'buffer_size_kb x CPUs x 2'.
> > 
> > Why two times difference is there? because ftrace implicitly allocate
> > the buffer for max latency too.
> > 
> > That makes sad result when admin want to use large buffer. (If admin
> > want full logging and makes detail analysis). example, If admin
> > have 24 CPUs machine and write 200MB to buffer_size_kb, the system
> > consume ~10GB memory (200MB x 24 x 2). umm.. 5GB memory waste is
> > usually unacceptable.
> > 
> > Fortunatelly, almost all users don't use max latency feature.
> > The max latency buffer can be disabled easily.
> > 
> > This patch shrink buffer size of the max latency buffer if
> > unnecessary.
> 
> Actually, what would be better is to add a "use_max_tr" field to the
> struct tracer in trace.h.  Then the latency tracers (irqsoff,
> preemptoff, preemptirqsoff, wakeup, and wakeup_rt) can have this field
> set.

Ah, Cool!


> 
> Then, we can resize or even remove the max ring buffer when the
> "use_max_tr" is not set (and on bootup). On enabling a latency tracer,
> we can allocate the buffer. When we enable another tracer (or nop) if
> the use_max_tr is not set, then we can remove the buffer.
> 
> Would you be able to do something like that?


How about this?