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 0/8] jump-label: allow early jump_label_enabl

To: Steven Rostedt <rostedt@xxxxxxxxxxx>
Subject: [Xen-devel] Re: [PATCH RFC 0/8] jump-label: allow early jump_label_enable()
From: Jeremy Fitzhardinge <jeremy@xxxxxxxx>
Date: Fri, 30 Sep 2011 09:09:40 -0700
Cc: Xen Devel <xen-devel@xxxxxxxxxxxxxxxxxxx>, Jan Glauber <jang@xxxxxxxxxxxxxxxxxx>, Jason Baron <jbaron@xxxxxxxxxx>, the arch/x86 maintainers <x86@xxxxxxxxxx>, David Daney <david.daney@xxxxxxxxxx>, Linux Kernel Mailing List <linux-kernel@xxxxxxxxxxxxxxx>, Michael Ellerman <michael@xxxxxxxxxxxxxx>, Jeremy Fitzhardinge <jeremy.fitzhardinge@xxxxxxxxxx>, "David S. Miller" <davem@xxxxxxxxxxxxx>
Delivery-date: Fri, 30 Sep 2011 09:12:34 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <1317396484.4588.52.camel@xxxxxxxxxxxxxxxxxxx>
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.1317338254.git.jeremy.fitzhardinge@xxxxxxxxxx> <1317343975.4588.36.camel@xxxxxxxxxxxxxxxxxxx> <4E854859.4020105@xxxxxxxx> <1317396484.4588.52.camel@xxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:6.0.2) Gecko/20110906 Thunderbird/6.0.2
On 09/30/2011 08:28 AM, Steven Rostedt wrote:
> On Thu, 2011-09-29 at 21:40 -0700, Jeremy Fitzhardinge wrote:
>> On 09/29/2011 05:52 PM, Steven Rostedt wrote:
>>> On Thu, 2011-09-29 at 16:26 -0700, Jeremy Fitzhardinge wrote:
>>>> From: Jeremy Fitzhardinge <jeremy.fitzhardinge@xxxxxxxxxx>
>>>>
>>>> One big question which arises is whether the _early() function is
>>>> necessary at all.  All the stop_machine/mutex/etc stuff that
>>>> arch_jump_label_transform() ends up doing is redundant pre-SMP, but it
>>>> shouldn't hurt.  Maybe we can just drop the _early function?  It works
>>>> on x86, at least, because jump_label_enable() works, which uses the full
>>>> form.  And dropping it would reduce this to a very much smaller series.
>>> It does slow down the boot process, which is not a good thing when
>>> everyone is pushing for the fastest restarts.
>> Would it really though?  stop_machine() doesn't do very much when there
>> are no other cpus.
>>
>> Not that I measured or anything, but there was no obvious big lag at boot.
> Just bringing up the point, but without measurements, its all hand
> waving. It may not be a big deal, and simpler code is always better if
> it doesn't harm anything else.

I think the simplest thing is to make stop_machine() well-defined in a
pre-smp environment, where it just directly calls the callback:

diff --git a/kernel/stop_machine.c b/kernel/stop_machine.c
index ba5070c..b6ad9b3 100644
--- a/kernel/stop_machine.c
+++ b/kernel/stop_machine.c
@@ -485,6 +485,11 @@ int __stop_machine(int (*fn)(void *), void *data, const 
struct cpumask *cpus)
                                            .num_threads = num_online_cpus(),
                                            .active_cpus = cpus };
 
+       if (smdata.num_threads == 1) {
+               (*fn)(data);
+               return 0;
+       }
+
        /* Set the initial state and stop all online cpus. */
        set_state(&smdata, STOPMACHINE_PREPARE);
        return stop_cpus(cpu_online_mask, stop_machine_cpu_stop, &smdata);

so that its guaranteed safe to use at any point.

    J

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