lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1339798214.25903.17.camel@gandalf.stny.rr.com>
Date:	Fri, 15 Jun 2012 18:10:14 -0400
From:	Steven Rostedt <rostedt@...dmis.org>
To:	"Luck, Tony" <tony.luck@...el.com>
Cc:	Anton Vorontsov <anton.vorontsov@...aro.org>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Kees Cook <keescook@...omium.org>,
	Colin Cross <ccross@...roid.com>,
	Frederic Weisbecker <fweisbec@...il.com>,
	Ingo Molnar <mingo@...hat.com>, Arnd Bergmann <arnd@...db.de>,
	John Stultz <john.stultz@...aro.org>,
	Shuah Khan <shuahkhan@...il.com>,
	"arve@...roid.com" <arve@...roid.com>,
	Rebecca Schultz Zavin <rebecca@...roid.com>,
	Jesper Juhl <jj@...osbits.net>,
	Randy Dunlap <rdunlap@...otime.net>,
	Stephen Boyd <sboyd@...eaurora.org>,
	Thomas Meyer <thomas@...3r.de>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Marco Stornelli <marco.stornelli@...il.com>,
	WANG Cong <xiyou.wangcong@...il.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"devel@...verdev.osuosl.org" <devel@...verdev.osuosl.org>,
	"linaro-kernel@...ts.linaro.org" <linaro-kernel@...ts.linaro.org>,
	"patches@...aro.org" <patches@...aro.org>,
	"kernel-team@...roid.com" <kernel-team@...roid.com>
Subject: RE: [PATCH 3/6] pstore: Add persistent function tracing

On Fri, 2012-06-15 at 22:00 +0000, Luck, Tony wrote:
> > With function tracing the impact to performance is tremendous. Just
> > recording two long words is a 130% hit to performance. Now multiply that
> > to recording strings.
> 
> If pstore is writing to a flash based backend - then there will be many
> milli-seconds of delay. I think the time taken to convert from binary to
> ascii would be insignificant.

milli-seconds for recording? This would cripple the kernel. On slow
machines, incorporating lockdep into function tracing (and other debug
options) causes the system to live lock. Tracing the timer interrupt
took so long that by the time it finished, the next timer triggered
again.

Heck, today you can pretty much live lock most machines if you enabled
the option 'func_stack_trace' while function tracing without filtering.
You may be able to get your system back again, but it usually takes
several seconds to acknowledge each key stroke (if you're lucky, but we
all know *you* are ;-)


If we are talking about milli-seconds to record. Then this is a no go,
as it wont be worth adding. I'm thinking their buffering system is much
faster than that today, as they have shown examples already.

-- 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

Powered by Openwall GNU/*/Linux Powered by OpenVZ