Re: [RFC] [PATCH 0/2] x86: make jump labels use int3-basedbreakpoint instead of stop_machine()
From: Steven Rostedt
Date: Thu Jul 11 2013 - 12:42:42 EST
On Thu, 2013-07-11 at 02:04 +0200, Jiri Kosina wrote:
> I even have preliminary (completely untested) patch, but would like to
> have this merged/acked in the first round before proceeding with porting
> ftrace to the new interface.
>
> > Also, I wonder if its worth batching up updates. For example, right now
> > we simply update each call-site one at a time even if its associated
> > with the same control variable.
>
> That does seem to make sense indeed, but it's not really closely tied to
> this patchset, is it?
If you want to have ftrace use this interface, then we need to support
batch processing. And you will need to do it with an iterator as well.
We can not allocate 30,000 locations to run this on. Ftrace has its own
table, and uses the ftrace iterator to traverse it.
Thus you would need to do something like:
int text_poke_iterator(struct text_poke_iter *iterator)
{
struct text_poke_iter_instance *iter;
for (iter = text_poke_iterator_start(iterator);
iter;
iter = text_poke_iterator_next(iterator)) {
ret = add_breakpoints(iter->addr, iter->old);
if (!ret)
goto failed;
}
on_each_cpu(do_sync_core, NULL, 1);
/* and this doesn't even handle the issue with ftrace
start up code */
for (iter = text_poke_iterator_start(iterator);
iter;
iter = text_poke_iterator_next(iterator)) {
ret = add_update(iter->addr, iter->old, iter->new);
if (!ret)
goto failed;
}
on_each_cpu(do_sync_core, NULL, 1);
for (iter = text_poke_iterator_start(iterator);
iter;
iter = text_poke_iterator_next(iterator)) {
ret = remove_breakpoints(iter->addr, iter->new);
if (!ret)
goto failed;
}
on_each_cpu(do_sync_core, NULL, 1);
return 0;
failed:
for (iter = text_poke_iterator_start(iterator);
iter;
iter = text_poke_iterator_next(iterator)) {
ret = remove_breakpoints_fail(iter->addr, iter->old, iter->new);
}
}
-- Steve
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/