Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Feature: Boost worker thread priority
Reason: The balloon worker thread may get starved and inflate/delate may take an unreasonably long time if the system is under CPU stress.
Result: This feature increases the base priority of the thread to
LOW_REALTIME_PRIORITY and adds the EVENT_INCREMENT dynamic priority boost to all KeSetEvent calls.
Created attachment 1257127[details]
balloon-stress-fail
Description of problem:
cost too much time when continues enlarge/evict during playing video
Version-Release number of selected component (if applicable):
virtio-win-prewhql-126
How reproducible:
5%
Steps to Reproduce:
1. boot guest with balloon device (guest memory more than 20G)
2. play a video in guest
3. during step 2, evict memory from 32G to 10G or other large memory evict
Actual results:
cost more than 4 min and it can evict but too slow, so it timeout in our script
At the begining
01:14:49 DEBUG| (monitor qmpmonitor1) actual: 28180480000
01:14:50 DEBUG| (monitor qmpmonitor1) Sending command 'query-balloon'
01:14:50 DEBUG| Send command: {'execute': 'query-balloon', 'id': 'LNcvXIiP'}
01:14:50 DEBUG| (monitor qmpmonitor1) Response to 'query-balloon' (re-formated)
01:14:50 DEBUG| (monitor qmpmonitor1) actual: 28151119872
At last
01:18:45 DEBUG| (monitor qmpmonitor1) actual: 17786994688
01:18:46 DEBUG| (monitor qmpmonitor1) Sending command 'query-balloon'
01:18:46 DEBUG| Send command: {'execute': 'query-balloon', 'id': 'WOT5PC6P'}
01:18:46 DEBUG| (monitor qmpmonitor1) Response to 'query-balloon' (re-formated)
01:18:46 DEBUG| (monitor qmpmonitor1) actual: 17740857344
01:18:47 DEBUG| (monitor qmpmonitor1) Sending command 'query-balloon'
01:18:47 DEBUG| Send command: {'execute': 'query-balloon', 'id': '1QhBi6Ks'}
01:18:47 DEBUG| (monitor qmpmonitor1) Response to 'query-balloon' (re-formated)
01:18:47 DEBUG| (monitor qmpmonitor1) actual: 17705205760
01:18:48 DEBUG| (monitor qmpmonitor1) Sending command 'query-balloon'
01:18:48 DEBUG| Send command: {'execute': 'query-balloon', 'id': 'YbRlGlgJ'}
01:18:48 DEBUG| (monitor qmpmonitor1) Response to 'query-balloon' (re-formated)
Expected results:
Faster and can evict/enlarge in 4min
Additional info:
More detail logs refer to the attachment
Based on xperf profiling, balloon.sys!BalloonFill is dominated by ntoskrnl.exe!MmAllocatePagesForMdlEx (~ 85%) which is the actual memory allocation kernel function. Video playback is unlikely to cause any kind of memory subsystem stress so the balloon worker thread is probably just starved, competing for the CPU with the real-time media player process.
Hi,
contract the balloon performance between build 126 and build 135(win8-64), the balloon time is shorter than before.
Steps:
1 boot guest with 32G mem and with balloon device
2 install build126
3 balloon to 1G
4 balloon to 32G
5 record the time of balloon
6 install build135
7 repeat step3-4
8 record the time of balloon
No. 32G->1G(build126) 1G->32G(126) 1G->32G(build135) 32G->1G(135)
1 66s 25s 38s 24s
1 48s 26s 37s 23s
2 53s 25s 34s 23s
3 45s 23s 33s 23s
According to the data, the balloon time is shorter than before. So this bug has been fixed.
Thanks
Yu Wang
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.
For information on the advisory, and where to find the updated
files, follow the link below.
If the solution does not work for you, open a new bug report.
https://access.redhat.com/errata/RHBA-2017:2341
Created attachment 1257127 [details] balloon-stress-fail Description of problem: cost too much time when continues enlarge/evict during playing video Version-Release number of selected component (if applicable): virtio-win-prewhql-126 How reproducible: 5% Steps to Reproduce: 1. boot guest with balloon device (guest memory more than 20G) 2. play a video in guest 3. during step 2, evict memory from 32G to 10G or other large memory evict Actual results: cost more than 4 min and it can evict but too slow, so it timeout in our script At the begining 01:14:49 DEBUG| (monitor qmpmonitor1) actual: 28180480000 01:14:50 DEBUG| (monitor qmpmonitor1) Sending command 'query-balloon' 01:14:50 DEBUG| Send command: {'execute': 'query-balloon', 'id': 'LNcvXIiP'} 01:14:50 DEBUG| (monitor qmpmonitor1) Response to 'query-balloon' (re-formated) 01:14:50 DEBUG| (monitor qmpmonitor1) actual: 28151119872 At last 01:18:45 DEBUG| (monitor qmpmonitor1) actual: 17786994688 01:18:46 DEBUG| (monitor qmpmonitor1) Sending command 'query-balloon' 01:18:46 DEBUG| Send command: {'execute': 'query-balloon', 'id': 'WOT5PC6P'} 01:18:46 DEBUG| (monitor qmpmonitor1) Response to 'query-balloon' (re-formated) 01:18:46 DEBUG| (monitor qmpmonitor1) actual: 17740857344 01:18:47 DEBUG| (monitor qmpmonitor1) Sending command 'query-balloon' 01:18:47 DEBUG| Send command: {'execute': 'query-balloon', 'id': '1QhBi6Ks'} 01:18:47 DEBUG| (monitor qmpmonitor1) Response to 'query-balloon' (re-formated) 01:18:47 DEBUG| (monitor qmpmonitor1) actual: 17705205760 01:18:48 DEBUG| (monitor qmpmonitor1) Sending command 'query-balloon' 01:18:48 DEBUG| Send command: {'execute': 'query-balloon', 'id': 'YbRlGlgJ'} 01:18:48 DEBUG| (monitor qmpmonitor1) Response to 'query-balloon' (re-formated) Expected results: Faster and can evict/enlarge in 4min Additional info: More detail logs refer to the attachment