lkml.org 
[lkml]   [2014]   [Jan]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH v6 7/8] x86: patch all traced function calls using the int3-based framework
On Thu, 23 Jan 2014 15:21:42 +0100
Petr Mladek <pmladek@suse.cz> wrote:

> It means that the slowness caused by tracing "text_poke*" stuff is
> comparable with the slowness caused by "run_sync()". It might mean that
> "text_poke_bp_list" is not worth the added complexity.

I'm starting to think it's fine keeping ftrace and text_poke separate.
Ftrace is rather the NMI of text modification. It's extremely invasive
and has more corner cases than anything else. I rather not complicate
the more generic text_poke just to satisfy ftrace. Perhaps if it was
not such an arch specific change it may be worth it. As these only have
to deal with x86, and the only rational in doing it is to get ftrace to
use text_poke() (one code base for all), I think we can drop it.

Having them separate isn't that bad either, as both get heavy testing
as they both are used in normal development.

>
> Well, the iterator-based implementation is complex but still faster.
> Also the many sync calls might be more painful for a busy system that
> heavy use of the int3 handler. So, "text_poke_bp_list" still might be
> useful.

That said, I'm sure text_poke can use some clean ups. That would be
nice as well. I think batch processing with the list may be more useful
for things like kprobes and jump labels.

-- Steve



\
 
 \ /
  Last update: 2014-01-23 17:41    [W:0.603 / U:0.164 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site