Messages in this thread | | | Date | Thu, 12 Mar 2009 23:20:45 -0400 (EDT) | From | Steven Rostedt <> | Subject | Re: [PATCH 05/16] tracing: show that buffer size is not expanded |
| |
On Fri, 13 Mar 2009, KOSAKI Motohiro wrote:
> > From: Steven Rostedt <srostedt@redhat.com> > > > > Impact: do not confuse user on small trace buffer sizes > > > > When the system boots up, the trace buffer is small to conserve memory. > > It is only two pages per online CPU. When the tracer is used, it expands > > to the default value. > > > > This can confuse the user if they look at the buffer size and see only > > 7, but then later they see 1408. > > > > # cat /debug/tracing/buffer_size_kb > > 7 > > > > # echo sched_switch > /debug/tracing/current_tracer > > > > # cat /debug/tracing/buffer_size_kb > > 1408 > > > > This patch tries to help remove this confustion by showing that the > > buffer has not been expanded. > > > > # cat /debug/tracing/buffer_size_kb > > 7 (expanded: 1408) > > Hi, > > I have one question. > Why souldn't use following output? > > sprintf(buf, "%lu\n", trace_buf_size >> 10); > > > My point is: > - pure number output can hadle easily. > - nobody need to know internal memory saving logic.
My answer to the second point is: "I do" ;-)
I like to know the real buffer size. That '7' comes from the ring buffer size directly. If something is going wrong, I do not want to hide the fact that the ring buffer size is not what I expect it to be. Lets say someone modifies the code, and we miss expanding the buffer. It will be very hard to debug why we are getting a small trace. But if we see that the buffer has not been expanded, we know exactly what is wrong.
-- Steve
| |