search for: stop_machin

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-of...

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-of...

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 o...

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 o...

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-...

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-...

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 >>> give up our CPU by using the new cpu_relax_yield. >> >> This seems something that would apply to most other virt stuff. Lets Cc >&gt...

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 reintroduced with commit 4d92f50249eb ("s390: reintroduce diag 44 calls for cpu_relax()")...

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 seems something that would apply to most other virt stuff. Lets Cc > a few more list...

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 return -EBUSY with some printk messages if any o...

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 return -EBUSY with some printk messages if any o...

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 u...

...s.runtime, > while discarding the .parainstructions as usual at init. This is then > used for switching back and forth between native and paravirt mode. > ([1] lists some representative numbers of the increased memory > footprint.) > > Mechanism: the patching itself is done using stop_machine(). That is > not ideal -- text_poke_stop_machine() was replaced with INT3+emulation > via text_poke_bp(), but I'm using this to address two issues: > 1) emulation in text_poke() can only easily handle a small set > of instructions and this is problematic for inlined pv-ops (and s...

...s.runtime, > while discarding the .parainstructions as usual at init. This is then > used for switching back and forth between native and paravirt mode. > ([1] lists some representative numbers of the increased memory > footprint.) > > Mechanism: the patching itself is done using stop_machine(). That is > not ideal -- text_poke_stop_machine() was replaced with INT3+emulation > via text_poke_bp(), but I'm using this to address two issues: > 1) emulation in text_poke() can only easily handle a small set > of instructions and this is problematic for inlined pv-ops (and s...

Btw., another question that made me wonder already when doing the original patch: why is it that x86-64 properly uses locking for mm_pin_all(), yet i386 doesn''t need to? Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel

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

..._poke_state.state = PATCH_SYNC_DONE; /* Start state */ > + text_poke_state.primary_cpu = smp_processor_id(); > + > + /* > + * Run the worker on all online CPUs. Don't need to do anything > + * for offline CPUs as they come back online with a clean cache. > + */ > + ret = stop_machine(patch_worker, &text_poke_state, cpu_online_mask); This.. that on its own is almost a reason to NAK the entire thing. We're all working very hard to get rid of stop_machine() and you're adding one. Worse, stop_machine() is notoriously crap on over-committed virt, the exact scenario wh...

...(1): Fix oops in acer_wmi driver (acer_wmi_init) are available in the git repository at: ssh://master.kernel.org/pub/scm/linux/kernel/git/rusty/linux-2.6-for-linus.git master Anthony Liguori (1): virtio_balloon: fix towards_target when deflating balloon Rusty Russell (3): stop_machine: wean Xen off stop_machine_run stop_machine: Remove deprecated stop_machine_run lguest: update commentry Documentation/lguest/lguest.c | 8 ++++++++ drivers/lguest/lguest_device.c | 8 ++++++++ drivers/virtio/virtio_balloon.c | 2 +- drivers/xen/manage.c | 2...

On 08.04.20 14:08, Peter Zijlstra wrote: > On Tue, Apr 07, 2020 at 10:02:57PM -0700, Ankur Arora wrote: >> Mechanism: the patching itself is done using stop_machine(). That is >> not ideal -- text_poke_stop_machine() was replaced with INT3+emulation >> via text_poke_bp(), but I'm using this to address two issues: >> 1) emulation in text_poke() can only easily handle a small set >> of instructions and this is problematic for inl...

...pport. Another thought inspired by Kevin, due to the time sequence that different cpus enter the stop machine context, there is a small window that some kind of softirqs (say softirq_A) are issued to the dying cpu right after the dying cpu has already handled softirq_A in do_softirq before entering stop_machine softirq. So this softirq_A should be handled by the dying cpu after exiting from stop_machine context. However, scheduling to idle leaves no change for softirqs other than the shedule softirq itself to execute. This patch will flush these softirqs at the beginning of play_dead. Best Regards Haita...