Re: [PATCH RFC V4 06/10] jump_label: addarch_jump_label_transform_static() to optimise non-live code updates

[Peter Zijlstra]

On Thu, 2011-10-13 at 11:55 -0400, Jason Baron wrote:
> > I actually need them to be either way.. no preference between on or off
> > just a means of very _very_ infrequent runtime change in behaviour.
> > 
> 
> ok, this is a new use case, all the current users are biased with gcc
> out-of-lining the infrequent case.

Right, 

> > If we can push jump_label init to before sched_init() all I need is a
> > static_branch() without the unlikely() in to avoid GCC out-of-lining the
> > branch.
> > 
> 
> hmmm....the current code (I believe) is biased  b/c gcc sees the
> branch as always false, see: arch_static_branch() - its not b/c we have
> an unlikely there. Without open coding the label, like we had before
> everybody hated, I'll have to play around and see what will create an
> unbiased branch...perhaps, somebody has an idea? 

Fix gcc and stick an unlikely in static_branch() ? :-)

> > > and by patching them early
> > > like this, at least for x86, we can avoid the stop machine calls. So its
> > > the combination of most are expected to be off and no sense to call extra
> > > stop machines that lead the code to its present state.
> > 
> > But we could use arch_jump_label_transform_static because its before we
> > actually execute any module text (sans the arg crap) which is
> > stomp-machine free, removing that obstacle.
> > 
> > Or am I confused more?
> > 
> 
> The MODULE_COMING callback happens *after* the call to flush_module_icache(mod),
> so I'm not sure that is safe... 

We can issue another one of those?
--
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/