lkml.org 
[lkml]   [2008]   [Dec]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: ftrace behaviour (was: [PATCH] ftrace: introduce tracing_reset_online_cpus() helper)

On Sat, 20 Dec 2008, Ingo Molnar wrote:
>
> uhm, the user just resized the buffer - he will not be wondering about any
> impact.

I can imagine some users that would ;-)

>
> And that's why we should do a full reset: that makes it abundantly clear
> what happened. We shouldnt pretend to be able to do something (seemless,
> lightweight buffer size change with no visible impact) which we obviously
> cannot reliably offer.

Some tracers, namely the latency ones (irqsoff and friends, as well as the
sched wakeup) need to resize two buffers, and if this is done while
tracing is enabled, the special "switch" operation can cause problems.
Keeping tracing on while resizing can be done, but it needs to done
carefully.

>
> Buffer resize is a slow op, and everyone realizes that. Most people will
> in fact say: "hey, I didnt even need to reboot to change the trace buffer
> size, cool!".

Exactly! Currently they will be happy that they do not need to reboot.

>
> The current "only allow resizing while tracing is disabled" is an
> unintuitive and counterproductive restriction - a borderline bug in fact.

Having to disable tracing to resize is much better than having to reboot.

I'm not defending that this is the way to go. I never planned on keeping
this the defacto standard. I've been setting up infrastructure to allow
for a seamless resize. If you think we should reset the buffers on resize,
then that would be a great way for the user to know why they are missing
**all** their data.

What I'm trying to say is that the more we allow during resize, the more
likely there will be a critical bug that might lock up the system. The
whole point about writing the ring buffer was to do it incrementally.
Start out with being straight forward and simple, then we could add
features as we understand things better.

IOW, I totally agree that we should make it as intuitive as possible. But
this needs to be done step by step. I wrote 10 different versions of the
ring buffer in a week. Most of them were complete rewrites. I want this to
be as robust and powerful as you do, but I also want to be cautious about
doing things that might crash the system.

Ftrace already had the infrastructure in place to protect against resize.
I just used it to give me time to do other things with the ring buffer.
I always planned on having the resize protection back inside the ring
buffer code when I got around to it.

-- Steve





\
 
 \ /
  Last update: 2008-12-20 01:31    [W:0.063 / U:0.532 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site