diff options
| author | Juergen Gross <[email protected]> | 2021-08-27 14:32:06 +0200 |
|---|---|---|
| committer | Juergen Gross <[email protected]> | 2021-09-14 09:53:48 +0200 |
| commit | 8480ed9c2bbd56fc86524998e5f2e3e22f5038f6 (patch) | |
| tree | 0436a0f5f79f1ae51e6816d13443b67bb5e54477 /scripts/gdb/linux/timerlist.py | |
| parent | 58e636039b512697554b579c2bb23774061877f5 (diff) | |
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 <[email protected]>
Signed-off-by: Juergen Gross <[email protected]>
Reviewed-by: Boris Ostrovsky <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Juergen Gross <[email protected]>
Diffstat (limited to 'scripts/gdb/linux/timerlist.py')
0 files changed, 0 insertions, 0 deletions