summaryrefslogtreecommitdiff
path: root/Documentation/iio
diff options
context:
space:
mode:
authorJuergen Gross <jgross@suse.com>2021-08-27 15:32:06 +0300
committerJuergen Gross <jgross@suse.com>2021-09-14 10:53:48 +0300
commit8480ed9c2bbd56fc86524998e5f2e3e22f5038f6 (patch)
tree0436a0f5f79f1ae51e6816d13443b67bb5e54477 /Documentation/iio
parent58e636039b512697554b579c2bb23774061877f5 (diff)
downloadlinux-8480ed9c2bbd56fc86524998e5f2e3e22f5038f6.tar.xz
xen/balloon: use a kernel thread instead a workqueue
Today the Xen ballooning is done via delayed work in a workqueue. This might result in workqueue hangups being reported in case of large amounts of memory are being ballooned in one go (here 16GB): BUG: workqueue lockup - pool cpus=6 node=0 flags=0x0 nice=0 stuck for 64s! Showing busy workqueues and worker pools: workqueue events: flags=0x0 pwq 12: cpus=6 node=0 flags=0x0 nice=0 active=2/256 refcnt=3 in-flight: 229:balloon_process pending: cache_reap workqueue events_freezable_power_: flags=0x84 pwq 12: cpus=6 node=0 flags=0x0 nice=0 active=1/256 refcnt=2 pending: disk_events_workfn workqueue mm_percpu_wq: flags=0x8 pwq 12: cpus=6 node=0 flags=0x0 nice=0 active=1/256 refcnt=2 pending: vmstat_update pool 12: cpus=6 node=0 flags=0x0 nice=0 hung=64s workers=3 idle: 2222 43 This can easily be avoided by using a dedicated kernel thread for doing the ballooning work. Reported-by: Jan Beulich <jbeulich@suse.com> Signed-off-by: Juergen Gross <jgross@suse.com> Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com> Link: https://lore.kernel.org/r/20210827123206.15429-1-jgross@suse.com Signed-off-by: Juergen Gross <jgross@suse.com>
Diffstat (limited to 'Documentation/iio')
0 files changed, 0 insertions, 0 deletions