drivers/virtio/virtio_balloon.c | 30 ++++++++++++++++++++++++++++- include/uapi/linux/virtio_balloon.h | 16 +++++++++++++-- 2 files changed, 43 insertions(+), 3 deletions(-)
Hi, When the guest runs under critial memory pressure, the guest becomss too slow, even sshd turns D state(uninterruptible) on memory allocation. We can't login this VM to do any work on trouble shooting. Guest kernel log via virtual TTY(on host side) only provides a few necessary log after OOM. More detail memory statistics are required, then we can know explicit memory events and estimate the pressure. I'm going to introduce several VM counters for virtio balloon: - oom-kill - alloc-stall - scan-async - scan-direct - reclaim-async - reclaim-direct Then we have a metric to analyze the memory performance: [also describe this metric in patch 'virtio_balloon: introduce memory scan/reclaim info'] y: counter increases n: counter does not changes h: the rate of counter change is high l: the rate of counter change is low OOM: VIRTIO_BALLOON_S_OOM_KILL STALL: VIRTIO_BALLOON_S_ALLOC_STALL ASCAN: VIRTIO_BALLOON_S_SCAN_ASYNC DSCAN: VIRTIO_BALLOON_S_SCAN_DIRECT ARCLM: VIRTIO_BALLOON_S_RECLAIM_ASYNC DRCLM: VIRTIO_BALLOON_S_RECLAIM_DIRECT - OOM[y], STALL[*], ASCAN[*], DSCAN[*], ARCLM[*], DRCLM[*]: the guest runs under really critial memory pressure - OOM[n], STALL[h], ASCAN[*], DSCAN[l], ARCLM[*], DRCLM[l]: the memory allocation stalls due to cgroup, not the global memory pressure. - OOM[n], STALL[h], ASCAN[*], DSCAN[h], ARCLM[*], DRCLM[h]: the memory allocation stalls due to global memory pressure. The performance gets hurt a lot. A high ratio between DRCLM/DSCAN shows quite effective memory reclaiming. - OOM[n], STALL[h], ASCAN[*], DSCAN[h], ARCLM[*], DRCLM[l]: the memory allocation stalls due to global memory pressure. the ratio between DRCLM/DSCAN gets low, the guest OS is thrashing heavily, the serious case leads poor performance and difficult trouble shooting. Ex, sshd may block on memory allocation when accepting new connections, a user can't login a VM by ssh command. - OOM[n], STALL[n], ASCAN[h], DSCAN[n], ARCLM[l], DRCLM[n]: the low ratio between ARCLM/ASCAN shows that the guest tries to reclaim more memory, but it can't. Once more memory is required in future, it will struggle to reclaim memory. zhenwei pi (3): virtio_balloon: introduce oom-kill invocations virtio_balloon: introduce memory allocation stall counter virtio_balloon: introduce memory scan/reclaim info drivers/virtio/virtio_balloon.c | 30 ++++++++++++++++++++++++++++- include/uapi/linux/virtio_balloon.h | 16 +++++++++++++-- 2 files changed, 43 insertions(+), 3 deletions(-) -- 2.34.1
On 15.04.24 10:41, zhenwei pi wrote: > Hi, > > When the guest runs under critial memory pressure, the guest becomss > too slow, even sshd turns D state(uninterruptible) on memory > allocation. We can't login this VM to do any work on trouble shooting. > > Guest kernel log via virtual TTY(on host side) only provides a few > necessary log after OOM. More detail memory statistics are required, > then we can know explicit memory events and estimate the pressure. > > I'm going to introduce several VM counters for virtio balloon: > - oom-kill > - alloc-stall > - scan-async > - scan-direct > - reclaim-async > - reclaim-direct IIUC, we're only exposing events that are already getting provided via all_vm_events(), correct? In that case, I don't really see a major issue. Some considerations: (1) These new events are fairly Linux specific. PSWPIN and friends are fairly generic, but HGTLB is also already fairly Linux specific already. OOM-kills don't really exist on Windows, for example. We'll have to be careful of properly describing what the semantics are. (2) How should we handle if Linux ever stops supporting a certain event (e.g., major reclaim rework). I assume, simply return nothing like we currently would for VIRTIO_BALLOON_S_HTLB_PGALLOC without CONFIG_HUGETLB_PAGE. -- Cheers, David / dhildenb
On 4/15/24 23:01, David Hildenbrand wrote: > On 15.04.24 10:41, zhenwei pi wrote: >> Hi, >> >> When the guest runs under critial memory pressure, the guest becomss >> too slow, even sshd turns D state(uninterruptible) on memory >> allocation. We can't login this VM to do any work on trouble shooting. >> >> Guest kernel log via virtual TTY(on host side) only provides a few >> necessary log after OOM. More detail memory statistics are required, >> then we can know explicit memory events and estimate the pressure. >> >> I'm going to introduce several VM counters for virtio balloon: >> - oom-kill >> - alloc-stall >> - scan-async >> - scan-direct >> - reclaim-async >> - reclaim-direct > > IIUC, we're only exposing events that are already getting provided via > all_vm_events(), correct? > Yes, all of these counters come from all_vm_events(). The 'alloc-stall' is summary of several classes of alloc-stall. please see '[RFC 2/3] virtio_balloon: introduce memory allocation stall counter'. > In that case, I don't really see a major issue. Some considerations: > > (1) These new events are fairly Linux specific. > > PSWPIN and friends are fairly generic, but HGTLB is also already fairly > Linux specific already. OOM-kills don't really exist on Windows, for > example. We'll have to be careful of properly describing what the > semantics are. > I also notice FreeBSD supports virtio balloon for a long time, 'OOM kill' is used on FreeBSD too.(LINK: https://klarasystems.com/articles/exploring-swap-on-freebsd/) > (2) How should we handle if Linux ever stops supporting a certain event > (e.g., major reclaim rework). I assume, simply return nothing like we > currently would for VIRTIO_BALLOON_S_HTLB_PGALLOC without > CONFIG_HUGETLB_PAGE. > Luckily, virtio balloon stats schema is tag-value style. This way would be safe enough. Suggestions in patch [1-3] are good, I'll fix them in the next version if this series is acceptable. -- zhenwei pi
© 2016 - 2026 Red Hat, Inc.