lkml.org 
[lkml]   [2013]   [Jul]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH 1/3] tracing: Use a ring buffer size of 1 when creating a new trace buffer
From
Date
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




\
 
 \ /
  Last update: 2013-07-02 03:02    [W:0.059 / U:0.456 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site