From: Peter Zijlstra Subject: Re: [PATCH RFC V4 06/10] jump_label: add arch_jump_label_transform_static() to optimise non-live code updates Date: Thu, 13 Oct 2011 18:32:05 +0200 Message-ID: <1318523526.27731.18.camel@twins> References: <16f652166605c973e9817177b6ba6a081e3e5b3f.1318464413.git.jeremy.fitzhardinge@citrix.com> <1318501954.24856.5.camel@twins> <20111013135439.GA2455@redhat.com> <1318519758.27731.15.camel@twins> <20111013155553.GD2455@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: <20111013155553.GD2455@redhat.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Jason Baron Cc: rth@redhat.com, Jeremy Fitzhardinge , the arch/x86 maintainers , "H. Peter Anvin" , Jeremy Fitzhardinge , Daney , Jan Glauber , Mailing List , Steven Rostedt , David, Michael Ellerman , Xen Devel , Linux, Ingo Molnar , "David S. Miller" List-Id: xen-devel@lists.xenproject.org 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. > >=20 >=20 > ok, this is a new use case, all the current users are biased with gcc > out-of-lining the infrequent case. Right,=20 > > 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 th= e > > branch. > >=20 >=20 > 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?=20 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 e= xtra > > > stop machines that lead the code to its present state. > >=20 > > 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. > >=20 > > Or am I confused more? > >=20 >=20 > The MODULE_COMING callback happens *after* the call to flush_module_icach= e(mod), > so I'm not sure that is safe...=20 We can issue another one of those?