similar to: [PULL] lguest comments, virtio fix and final stop_machine_run() remove

This is the last use of (the deprecated) stop_machine_run in the tree. Signed-off-by: Rusty Russell <rusty at rustcorp.com.au> diff -r 332ec042cb4d drivers/xen/manage.c --- a/drivers/xen/manage.c Wed Aug 13 10:48:27 2008 +1000 +++ b/drivers/xen/manage.c Wed Aug 13 15:50:02 2008 +1000 @@ -102,7 +102,7 @@ static void do_suspend(void) /* XXX use normal device tree? */ xenbus_suspend();

On kvm I have seen some rare hangs in stop_machine when I used more guest cpus than hosts cpus. e.g. 32 guest cpus on 1 host cpu triggered the hang quite often. I could also reproduce the problem on a 4 way z/VM host with a 64 way guest. It turned out that the guest was consuming all available cpus mostly for spinning on scheduler locks like rq->lock. This is expected as the threads are

On kvm I have seen some rare hangs in stop_machine when I used more guest cpus than hosts cpus. e.g. 32 guest cpus on 1 host cpu triggered the hang quite often. I could also reproduce the problem on a 4 way z/VM host with a 64 way guest. It turned out that the guest was consuming all available cpus mostly for spinning on scheduler locks like rq->lock. This is expected as the threads are

If stop_machine() invoked while one of onlined cpu is locked up by some reason, stop_machine cannot finish its work because the locked cpu cannot stop. This means all other healthy cpus will be blocked infinitely by one dead cpu. This patch allows stop_machine to return -EBUSY with some printk messages if any of stop_machine's threads cannot start running on its target cpu in time. You can

If stop_machine() invoked while one of onlined cpu is locked up by some reason, stop_machine cannot finish its work because the locked cpu cannot stop. This means all other healthy cpus will be blocked infinitely by one dead cpu. This patch allows stop_machine to return -EBUSY with some printk messages if any of stop_machine's threads cannot start running on its target cpu in time. You can

Thank you for useful feedbacks! Here is the updated version. Could you put this on top of your patches, Rusty? Thanks, H.Seto If stop_machine() invoked while one of onlined cpu is locked up by some reason, stop_machine cannot finish its work because the locked cpu cannot stop. This means all other healthy cpus will be blocked infinitely by one dead cpu. This patch allows stop_machine to

Thank you for useful feedbacks! Here is the updated version. Could you put this on top of your patches, Rusty? Thanks, H.Seto If stop_machine() invoked while one of onlined cpu is locked up by some reason, stop_machine cannot finish its work because the locked cpu cannot stop. This means all other healthy cpus will be blocked infinitely by one dead cpu. This patch allows stop_machine to

On 10/22/2016 02:06 AM, Nicholas Piggin wrote: > On Fri, 21 Oct 2016 14:05:36 +0200 > Peter Zijlstra <peterz at infradead.org> wrote: > >> On Fri, Oct 21, 2016 at 01:58:55PM +0200, Christian Borntraeger wrote: >>> stop_machine can take a very long time if the hypervisor does >>> overcommitment for guest CPUs. When waiting for "the one", lets

The following changes since commit 886c35fbcf6fb2eee15687efc2d64d99b6ad9a4a: Linus Torvalds (1): Merge branch 'for-linus' of git://git.kernel.org/.../ieee1394/linux1394-2.6 are available in the git repository at: ssh://master.kernel.org/pub/scm/linux/kernel/git/rusty/linux-2.6-for-linus.git master Christian Borntraeger (1): virtio: export more headers to userspace

The following changes since commit 886c35fbcf6fb2eee15687efc2d64d99b6ad9a4a: Linus Torvalds (1): Merge branch 'for-linus' of git://git.kernel.org/.../ieee1394/linux1394-2.6 are available in the git repository at: ssh://master.kernel.org/pub/scm/linux/kernel/git/rusty/linux-2.6-for-linus.git master Christian Borntraeger (1): virtio: export more headers to userspace

Some time ago commit 57f2ffe14fd125c2 ("s390: remove diag 44 calls from cpu_relax()") did stop cpu_relax on s390 yielding to the hypervisor. As it turns out this made stop_machine run really slow on virtualized overcommited systems. For example the kprobes test during bootup took several seconds instead of just running unnoticed with large guests. Therefore, the yielding was

On Fri, 21 Oct 2016 14:05:36 +0200 Peter Zijlstra <peterz at infradead.org> wrote: > On Fri, Oct 21, 2016 at 01:58:55PM +0200, Christian Borntraeger wrote: > > stop_machine can take a very long time if the hypervisor does > > overcommitment for guest CPUs. When waiting for "the one", lets > > give up our CPU by using the new cpu_relax_yield. > > This

On Fri, Oct 21, 2016 at 01:58:55PM +0200, Christian Borntraeger wrote: > stop_machine can take a very long time if the hypervisor does > overcommitment for guest CPUs. When waiting for "the one", lets > give up our CPU by using the new cpu_relax_yield. This seems something that would apply to most other virt stuff. Lets Cc a few more lists for that. > Signed-off-by:

On Fri, Oct 21, 2016 at 01:58:55PM +0200, Christian Borntraeger wrote: > stop_machine can take a very long time if the hypervisor does > overcommitment for guest CPUs. When waiting for "the one", lets > give up our CPU by using the new cpu_relax_yield. This seems something that would apply to most other virt stuff. Lets Cc a few more lists for that. > Signed-off-by:

add xen_timer_resume() hook. Timer resume should be done after event channel is resumed. add xen_arch_resume() hook when ipi becomes usable after resume. After resume, some cpu specific resource must be reinitialized on ia64 that can't be set by another cpu. However available hooks is run once on only one cpu so that ipi has to be used. During stop_machine_run() ipi can't be used because

add xen_timer_resume() hook. Timer resume should be done after event channel is resumed. add xen_arch_resume() hook when ipi becomes usable after resume. After resume, some cpu specific resource must be reinitialized on ia64 that can't be set by another cpu. However available hooks is run once on only one cpu so that ipi has to be used. During stop_machine_run() ipi can't be used because

add xen_timer_resume() hook. Timer resume should be done after event channel is resumed. add xen_arch_resume() hook when ipi becomes usable after resume. After resume, some cpu specific resource must be reinitialized on ia64 that can't be set by another cpu. However available hooks is run once on only one cpu so that ipi has to be used. During stop_machine_run() ipi can't be used because

This patch implements cpu offline feature. Best Regards Haitao Shan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel

On Tue, Apr 07, 2020 at 10:03:12PM -0700, Ankur Arora wrote: > +static int __maybe_unused text_poke_late(patch_worker_t worker, void *stage) > +{ > + int ret; > + > + lockdep_assert_held(&text_mutex); > + > + if (system_state != SYSTEM_RUNNING) > + return -EINVAL; > + > + text_poke_state.stage = stage; > + text_poke_state.num_acks =

Thankx MC, This is the solution. I've tried it and it works perfect. But I've got a question. I want to set a variable with the command SetVar I place the following text file in the directory /var/spool/asterisk/outgoing/ Channel: Zap/g1/0655871460 MaxRetries: 0 RetryTime: 30 WaitTime: 30 Context: call_outbound Extension: s Priority: 1 SetVar: call_outbound_id=0