linux-ext4 - Re: [PATCH 1/1] x86: fix text

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: <48151F15.7050606@redhat.com>
Date:	Sun, 27 Apr 2008 20:49:25 -0400
From:	Masami Hiramatsu <mhiramat@...hat.com>
To:	Jeremy Fitzhardinge <jeremy@...p.org>
CC:	Mathieu Desnoyers <mathieu.desnoyers@...ymtl.ca>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	"H. Peter Anvin" <hpa@...or.com>, Andi Kleen <andi@...stfloor.org>,
	Ingo Molnar <mingo@...e.hu>, Jiri Slaby <jirislaby@...il.com>,
	David Miller <davem@...emloft.net>, zdenek.kabelac@...il.com,
	rjw@...k.pl, paulmck@...ux.vnet.ibm.com, akpm@...ux-foundation.org,
	linux-ext4@...r.kernel.org, herbert@...dor.apana.org.au,
	penberg@...helsinki.fi, clameter@....com,
	linux-kernel@...r.kernel.org, pageexec@...email.hu
Subject: Re: [PATCH 1/1] x86: fix text_poke

Jeremy Fitzhardinge wrote:
> Mathieu Desnoyers wrote:
>> * Linus Torvalds (torvalds@...ux-foundation.org) wrote:
>>   
>>> On Fri, 25 Apr 2008, H. Peter Anvin wrote:
>>>     
>>>> Yes, that should work.  It's still ugly, and I have to say I find the
>>>> complexity rather distasteful.  I am willing to be convinced it's worth it,
>>>> but I would really like to see hard numbers.
>>>>       
>>> I really cannot imagine that this kind of pain is *ever* worth it. 
>>>
>>> Please give an example of something so important that we'd want to do 
>>> complex code rewriting on the fly. What _is_ the point of imv_cond()?
>>>
>>> 		Linus
>>>     
>> The point is to provide a way to dynamically enable code at runtime
>> without noticeable performance impact on the system. It's principally
>> useful to control the markers in the kernel, which can be placed in very
>> frequently executed code paths. The original markers add a memory read,
>> test and conditional branch at each marker site. By using the immediate
>> values patchset, it goes down to a load immediate value, test and branch.
>>
>> However, Ingo was still unhappy with the conditional branch, so I cooked
>> this jump patching optimization on top of the immediate values. 
> 
> I think all this demonstrates that the conditional branch is a bearable 
> cost compared to the alternative.  A conditional branch which almost 
> always branches the same way is very predictable, and really shouldn't 
> cost very much.

I agree with you.

When I measured the performance of a tracer (LKST) which used conditional
branches, the overhead of the conditional branch itself was very small
(less than 1%).
Moreover, some benchmarks showed the performance of the patched kernel
became ~1% faster than before :-) (I guessed that came from changing of
memory access pattern and timing.)

I think, if someone is considering about the actual performance impacts,
we'd better discuss the effects of the individual trace points, based
on the actual results of some benchmarks.
Thus, we can improve it step by step.

Thank you,

-- 
Masami Hiramatsu

Software Engineer
Hitachi Computer Products (America) Inc.
Software Solutions Division

e-mail: mhiramat@...hat.com

--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html