RE: [RFC][PATCH 0/4] ftrace: Use -mfentry when supported (this isfor x86_64 right now)

[Dominique Toupin]

If it's 1 us it might be OK for some of our "server" type of system, still the number of cores are growing quite fast and stopping _all_ of them is a bit scary. Some cores are dedicated to a special telecom subsystem which is very sensitive to even very small hic-up, we don't want to stop those cores.

As background info, we can use GDB dynamic tracepoint in those systems because GDB doesn't stop all cores when the tracepoint are inserted with a jump.


> -----Original Message-----
> From: Steven Rostedt [mailto:rostedt@xxxxxxxxxxx] 
> Sent: 18-Feb-11 15:37
> To: Dominique Toupin
> Cc: Mathieu Desnoyers; Masami Hiramatsu; 
> linux-kernel@xxxxxxxxxxxxxxx; Ingo Molnar; Andrew Morton; 
> Thomas Gleixner; Frederic Weisbecker; H. Peter Anvin; Andi 
> Kleen; 2nddept-manager@xxxxxxxxxxxxxxxxx
> Subject: RE: [RFC][PATCH 0/4] ftrace: Use -mfentry when 
> supported (this is for x86_64 right now)
> 
> On Fri, 2011-02-18 at 15:10 -0500, Dominique Toupin wrote:
> > My understanding is stop_machine will stop all processors 
> for many ms.
> 
> s/ms/us/
> 
> 
> > Even if most of our systems are not hard real-time they are 
> soft real-time and stopping all cores for a few ms is not allowed.
> > We can stop a few threads while we are jump patching but 
> all processors is too much for us.
> 
> I think I could hit a single ms if we enable full function 
> tracing which disables ~22,000 functions in one shot. But if 
> you enable full function tracing, the kernel can slow down 
> quite drastically, and that would even be more problematic 
> than a single ms hic-up. As hackbench showed a %150 slowdown 
> when function tracer was running.
> 
> Now the last measurements I took was a few years ago and it 
> was on a 4 CPU box. Perhaps stop_machine() may be a bit more 
> expensive on a 1024 CPU box.
> 
> -- Steve
> 
> 
> --
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/