[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <D58A856745AB5A47B1448181D1A8BBFA07673BC2D6@EUSAACMS0701.eamcs.ericsson.se>
Date: Fri, 18 Feb 2011 16:45:31 -0500
From: Dominique Toupin <dominique.toupin@...csson.com>
To: Steven Rostedt <rostedt@...dmis.org>
CC: Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
Masami Hiramatsu <masami.hiramatsu.pt@...achi.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Ingo Molnar <mingo@...e.hu>,
Andrew Morton <akpm@...ux-foundation.org>,
Thomas Gleixner <tglx@...utronix.de>,
Frederic Weisbecker <fweisbec@...il.com>,
"H. Peter Anvin" <hpa@...or.com>, Andi Kleen <andi@...stfloor.org>,
"2nddept-manager@....hitachi.co.jp"
<2nddept-manager@....hitachi.co.jp>
Subject: RE: [RFC][PATCH 0/4] ftrace: Use -mfentry when supported (this is
for x86_64 right now)
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@...dmis.org]
> Sent: 18-Feb-11 15:37
> To: Dominique Toupin
> Cc: Mathieu Desnoyers; Masami Hiramatsu;
> linux-kernel@...r.kernel.org; Ingo Molnar; Andrew Morton;
> Thomas Gleixner; Frederic Weisbecker; H. Peter Anvin; Andi
> Kleen; 2nddept-manager@....hitachi.co.jp
> 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@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists