linux-kernel - Re: [PATCH 1/3] tracing: Use a ring buffer size of 1 when creating a new trace buffer

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]

Date:	Mon, 01 Jul 2013 20:16:44 -0400
From:	Steven Rostedt <rostedt@...dmis.org>
To:	Alexander Z Lam <azl@...gle.com>
Cc:	linux-kernel@...r.kernel.org, David Sharp <dhsharp@...gle.com>,
	Vaibhav Nagarnaik <vnagarnaik@...gle.com>,
	Alexander Z Lam <lambchop468@...il.com>
Subject: Re: [PATCH 1/3] tracing: Use a ring buffer size of 1 when creating
 a new trace buffer

On Mon, 2013-07-01 at 15:31 -0700, Alexander Z Lam wrote:
> Use deferred ring buffer allocation in new trace buffer instances by
> copying the behavior of the deferred allocation of global_trace's buffer.
> Without this, each new trace buffer instance will attempt to allocate
> num_cpus * TRACE_BUF_SIZE_DEFAULT bytes for the ring buffer, which might
> fail on a system with many cores. If this fails, the new instance is not
> created, precluding the user from setting a smaller buffer for which
> allocation might succeed.
> 

Actually no, I don't like this approach. The reason for the expanded
buffer for ftrace is because we wanted distros to configure it enabled,
thus we needed a way not to waste memory in the buffers for tracing
which is used by 1% of distro uses, and the 99% of distro uses just have
wasted memory.

The reason I don't like this, is because it can fail to allocate when
the user starts the trace, which may cause strange results. For the main
buffer, we need to deal with this because of the distro issue. There's
plenty of ways to allocate the buffer on boot up in case you don't want
to worry about the buffer later. But for instances, I think the creation
of the instance should be dependent on whether or not you have the space
for the buffer, and not to find this out at time of starting the trace.

Now, the solution you do want is a new file called,
"instance_default_buffer_size_kb", that is used when creating a new
buffer. That is, let users change what a new instance buffer size will
be.

By default, this should be what the buffer_size is. Perhaps have it
change with the buffer_size as long as the
instance_default_buffer_size_kb hasn't changed manually yet.

-- 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/