Re: ftrace behaviour (was: [PATCH] ftrace: introducetracing_reset_online_cpus() helper)

[Pekka Paalanen]

On Fri, 19 Dec 2008 19:29:30 -0500 (EST)
Steven Rostedt <rostedt@xxxxxxxxxxx> wrote:

> On Sat, 20 Dec 2008, Ingo Molnar wrote:
> > 
> > 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.

I thought this was just about not having to do

$ echo 0 > tracing_enabled
$ echo 28764243 > buffer_size
$ echo 1 > tracing_enabled

and instead just do

$ echo 28764243 > buffer_size

which would do exactly the same, except being easier for the user.
Personally I've never dreamed of any kind of resize-in-flight.

> 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

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