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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1277948436.25782.5.camel@gandalf.stny.rr.com>
Date:	Wed, 30 Jun 2010 21:40:36 -0400
From:	Steven Rostedt <rostedt@...dmis.org>
To:	KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>
Cc:	LKML <linux-kernel@...r.kernel.org>,
	Li Zefan <lizf@...fujitsu.com>,
	Frederic Weisbecker <fweisbec@...il.com>,
	Ingo Molnar <mingo@...e.hu>
Subject: Re: [PATCH] tracing: shrink max latency ringbuffer if unnecessary

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


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/