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]
Date:	Fri, 01 Jun 2012 13:53:28 +0900
From:	Masami Hiramatsu <masami.hiramatsu.pt@...achi.com>
To:	Steven Rostedt <rostedt@...dmis.org>
Cc:	Peter Zijlstra <peterz@...radead.org>,
	Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
	linux-kernel@...r.kernel.org, Ingo Molnar <mingo@...e.hu>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Frederic Weisbecker <fweisbec@...il.com>,
	"H. Peter Anvin" <hpa@...or.com>, Dave Jones <davej@...hat.com>,
	Andi Kleen <ak@...ux.intel.com>,
	acme <acme@...stprotocols.net>, yrl.pp-manager.tt@...achi.com
Subject: Re: Re: [PATCH 1/5] ftrace: Synchronize variable setting with
 breakpoints

(2012/06/01 5:49), Steven Rostedt wrote:
> On Thu, 2012-05-31 at 22:40 +0200, Peter Zijlstra wrote:
>> On Thu, 2012-05-31 at 16:37 -0400, Steven Rostedt wrote:
>>> On Thu, 2012-05-31 at 22:26 +0200, Peter Zijlstra wrote:
>>>
>>>> Right, but when you loose stop-machine you could simply do 30k
>>>> kmap_atomic/kunmap_atomic's consecutively since you're not holding
>>>> anybody up.
>>>
>>> It requires 3 IPIs per update too. Thus that's 90,000 IPIs you are
>>> blasting^Wsending to all CPUs.
>>
>> Uhm, no. 
>>
> 
> ----------------------------------+
>> for_each() {			|
>>   kmap_atomic()			|
>>   frob int3			|
>>   kunmap_atomic();		|
>> }				|
>> 				|
>> sync-ipi-broadcast();		+--- Break points applied
>> 				|
>> for_each() {			|
>>   kmap_atomic();		|
>>   frob tail			|
>>   kunmap_atomic();		|
>> }				|
> ----------------------------------+
> 
> Note, for the above time, the entire kernel has breakpoints added, and
> every function is taking a hit due to it. By slowing down this process,
> the rest of the system *will* be impacted. Ideally, we want to finish it
> as quick as possible. Not to mention, the kmap_atomics will be slowed
> down by the breakpoints that are attached to them.

Hmm, why don't we have two text_poke interfaces for single and
batch? As like dyn_ftrace, since modifying massive points takes
a lot time, so we may have additional kconfig something like
CONFIG_QUICK_BATCH_TEXT_POKE which switches text area to rw while
batch text_poke.

Thank you,

-- 
Masami HIRAMATSU
Software Platform Research Dept. Linux Technology Center
Hitachi, Ltd., Yokohama Research Laboratory
E-mail: masami.hiramatsu.pt@...achi.com
--
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