[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <1318523526.27731.18.camel@twins>
Date: Thu, 13 Oct 2011 18:32:05 +0200
From: Peter Zijlstra <peterz@...radead.org>
To: Jason Baron <jbaron@...hat.com>
Cc: Jeremy Fitzhardinge <jeremy@...p.org>,
Steven Rostedt <rostedt@...dmis.org>,
"David S. Miller" <davem@...emloft.net>,
David Daney <david.daney@...ium.com>,
Michael Ellerman <michael@...erman.id.au>,
Jan Glauber <jang@...ux.vnet.ibm.com>,
the arch/x86 maintainers <x86@...nel.org>,
Xen Devel <xen-devel@...ts.xensource.com>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Ingo Molnar <mingo@...e.hu>, "H. Peter Anvin" <hpa@...or.com>,
Jeremy Fitzhardinge <jeremy.fitzhardinge@...rix.com>,
rth@...hat.com
Subject: Re: [PATCH RFC V4 06/10] jump_label: add
arch_jump_label_transform_static() to optimise non-live code updates
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@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists