WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

[Xen-devel] Re: [PATCH RFC V2 3/5] jump_label: if a key has already been

To: Jason Baron <jbaron@xxxxxxxxxx>
Subject: [Xen-devel] Re: [PATCH RFC V2 3/5] jump_label: if a key has already been initialized, don't nop it out
From: Steven Rostedt <rostedt@xxxxxxxxxxx>
Date: Mon, 03 Oct 2011 11:47:26 -0400
Cc: Jeremy Fitzhardinge <jeremy@xxxxxxxx>, the arch/x86 maintainers <x86@xxxxxxxxxx>, Jeremy Fitzhardinge <jeremy.fitzhardinge@xxxxxxxxxx>, Jan Glauber <jang@xxxxxxxxxxxxxxxxxx>, peterz@xxxxxxxxxxxxx, David Daney <david.daney@xxxxxxxxxx>, Michael, Linux Kernel Mailing List <linux-kernel@xxxxxxxxxxxxxxx>, Ellerman <michael@xxxxxxxxxxxxxx>, Xen Devel <xen-devel@xxxxxxxxxxxxxxxxxxx>, "David S. Miller" <davem@xxxxxxxxxxxxx>
Delivery-date: Mon, 03 Oct 2011 08:48:17 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <20111003150205.GB2462@xxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <cover.1317506051.git.jeremy.fitzhardinge@xxxxxxxxxx> <477dead9647029012f93c651f2892ed0e86b89e7.1317506051.git.jeremy.fitzhardinge@xxxxxxxxxx> <20111003150205.GB2462@xxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
On Mon, 2011-10-03 at 11:02 -0400, Jason Baron wrote:

> if (!enabled)
>       arch_jump_label_transform(iter, JUMP_LABEL_DISABLE);
> 
> 
> > +           if (iterk == key)
> >                     continue;
> >  
> > -           key = (struct jump_label_key *)(unsigned long)iter->key;
> > -           atomic_set(&key->enabled, 0);
> > +           key = iterk;
> >             key->entries = iter;
> >  #ifdef CONFIG_MODULES
> >             key->next = NULL;
> > @@ -212,7 +208,7 @@ void jump_label_apply_nops(struct module *mod)
> >             return;
> >  
> >     for (iter = iter_start; iter < iter_stop; iter++)
> > -           arch_jump_label_text_poke_early(iter->code);
> > +           arch_jump_label_transform(iter, JUMP_LABEL_DISABLE);
> >  }
> >  
> >  static int jump_label_add_module(struct module *mod)
> > -- 
> > 1.7.6.2
> > 
> 
> hmmm...this is used on module load in smp - so this would introduce a number 
> of
> calls to stop_machine() where we didn't have them before. Yes, module
> load is a very slow path to begin with, but I think its at least worth
> pointing out...

And it is a good point to point out. As stop_machine becomes noticeable
by users on large scale CPU boxes. Ideally, we want to avoid stopmachine
when we do not need it.

-- Steve



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel

<Prev in Thread] Current Thread [Next in Thread>