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

[Steven Rostedt <rostedt@goodmis.org>]

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.

(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.

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?

Thanks,

-- Steve