similar to: [PATCH] stopmachine: add stopmachine_timeout v2

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

On Monday 14 July 2008 21:51:25 Christian Borntraeger wrote: > Am Montag, 14. Juli 2008 schrieb Hidetoshi Seto: > > + /* Wait all others come to life */ > > + while (cpus_weight(prepared_cpus) != num_online_cpus() - 1) { > > + if (time_is_before_jiffies(limit)) > > + goto timeout; > > + cpu_relax(); > > + } > > + > > Hmm. I think this could

On Monday 14 July 2008 21:51:25 Christian Borntraeger wrote: > Am Montag, 14. Juli 2008 schrieb Hidetoshi Seto: > > + /* Wait all others come to life */ > > + while (cpus_weight(prepared_cpus) != num_online_cpus() - 1) { > > + if (time_is_before_jiffies(limit)) > > + goto timeout; > > + cpu_relax(); > > + } > > + > > Hmm. I think this could

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

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

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

Hi Seto, please could you update also the man page too ? Why it was not provided a way to clear a *single* flag ? To me it seems a bit too long to clear all the flag (btrfs mount-option clear) and then set the right one. As user interface I suggest something like chmod: btrfs mount-option set +ssd,skip_balance -nodatacow /dev/sdX or btrfs mount-option set =ssd,skip_balance,nodatacow

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:

Here are 3 patches to avoid undesired aborts of mkfs.btrfs. These are based on top of Chris''s btrfs-progs.git: git://git.kernel.org/pub/scm/linux/kernel/git/mason/btrfs-progs.git Thanks, H.Seto Hidetoshi Seto (3): btrfs-progs: error if device for mkfs is too small btrfs-progs: error if device have no space to make primary chunks btrfs-progs: calculate available

Since the d_off in the first dirent for "." (that originates from the 4th argument "offset" of filldir() for the 2nd dirent for "..") is wrongly assigned in btrfs_real_readdir(), telldir returns same offset for different locations. | # mkfs.btrfs /dev/sdb1 | # mount /dev/sdb1 fs0 | # cd fs0 | # touch file0 file1 | # ../test | telldir: 0 | readdir: d_off = 2,

The following changes since commit 83097aca8567a0bd593534853b71fe0fa9a75d69: Arjan van de Ven (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):

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 =

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();

Hi, Keir, Thanks for checking in cpu online/offline support. 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

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

On Tue, Apr 07, 2020 at 10:02:57PM -0700, Ankur Arora wrote: > A KVM host (or another hypervisor) might advertise paravirtualized > features and optimization hints (ex KVM_HINTS_REALTIME) which might > become stale over the lifetime of the guest. For instance, the > host might go from being undersubscribed to being oversubscribed > (or the other way round) and it would make sense