On Fri, 18 Oct 2013 10:55:57 -0400 Steven Rostedt <rost...@goodmis.org> wrote:
> On Fri, 18 Oct 2013 16:27:24 +0200 > Petr Mladek <pmla...@suse.cz> wrote: > > > > +/* > > + * We do not want to replace ftrace calls one by one because syncing all > > CPUs > > + * is quite expensive. > > + * > > + * On the other hand, we do not want to modify all calls at once because > > + * the buffers for text_poke_bp might be quite huge. Also we do not want > > + * to count the number of records before the allocation. > > + * > > + * Let's modify the call in batches defined by this define. > > + */ > > +#define FTRACE_MAX_RECS_PATCH 8192 > > > > -static int finish_update(struct dyn_ftrace *rec, int enable) > > +static int ftrace_allocate_replace_buffers(unsigned long **addr, void > > **opcode) > > I absolutely hate this. Current ftrace conversion does not need to > allocate at all. I want to keep it that way. > I should clarify that I do not hate the patch set. I actually like what it's trying to achieve (a lot!). But I absolutely hate having to copy records to do the bulk conversion. That part I'm giving a NAK to. Add a text_poke_bp_iterate() or something, that removes the need for allocating extra buffers, then I'll be very happy :-) -- Steve -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/