Bug 1688090
Summary: | [RFE] Provide a way to customize the poll-max-ns property of each iothread | ||
---|---|---|---|
Product: | Red Hat Enterprise Linux Advanced Virtualization | Reporter: | Han Han <hhan> |
Component: | libvirt | Assignee: | Libvirt Maintainers <libvirt-maint> |
Status: | CLOSED ERRATA | QA Contact: | gaojianan <jgao> |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | 8.0 | CC: | berrange, coli, dyuan, dzheng, fgarciad, gveitmic, hhan, jdenemar, jferlan, jiyan, jsuchane, knoel, laine, ldelouw, lhuang, michal.skrivanek, mkalinin, mtessun, slopezpa, stefanha, xuzhang, yafu |
Target Milestone: | rc | Keywords: | Automation, FutureFeature |
Target Release: | 8.0 | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | |||
Fixed In Version: | libvirt-5.0.0-1.el8 | Doc Type: | Enhancement |
Doc Text: | Story Points: | --- | |
Clone Of: | 1545732 | Environment: | |
Last Closed: | 2019-05-29 16:05:30 UTC | Type: | Feature Request |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: | |||
Bug Depends On: | 1545732 | ||
Bug Blocks: | 1477664 |
Comment 2
gaojianan
2019-03-28 08:31:47 UTC
The task was just to allow the values to changes. Understanding how that impacts performance is the more difficult technical detail to describe. Details for that are mostly left to those that understand QEMU IOThreads and the polling values. It's really dependent upon workload and sizing - difficult to just here use these numbers. (In reply to John Ferlan from comment #3) > The task was just to allow the values to changes. Understanding how that > impacts performance is the more difficult technical detail to describe. > Details for that are mostly left to those that understand QEMU IOThreads and > the polling values. It's really dependent upon workload and sizing - > difficult to just here use these numbers. Thanks for your answer John, we'd like to needinfo the qemu devel to check what's their opinion since it seems no qemu BZ to track the live update of poll-max-ns, we'd like to add a testing in qemu layer for the performance testing. Hi, Stefan, As we mentioned above, the function of live update poll-max-ns is supported and working well in libvirt currently, so we change the BZ status to verified now. But I'm not sure if we need to have a performance testing for the live update poll-max-ns in qemu layer? This feature is support in qemu from RHEL7.4, and it seems the performance is not improved so much from your comments[1]. So, how do you think about it now? do we need to add a performance testing in qemu layer? If yes, would you please give us some data for reference to design the performance testing scenarios? Thx. [1] https://bugzilla.redhat.com/show_bug.cgi?id=1404303#c7 "so it's unlikely that much higher numbers will improve performance. Most users should not need to set the poll-max-ns parameter." (In reply to Xuesong Zhang from comment #4) > As we mentioned above, the function of live update poll-max-ns is supported > and working well in libvirt currently, so we change the BZ status to > verified now. But I'm not sure if we need to have a performance testing for > the live update poll-max-ns in qemu layer? If you want to test that poll-max-ns has an effect on I/O request latency you could use null_blk with the completion_nsec= parameter and fio settings that fall within the poll-max-ns threshold. It would detect when poll-max-ns breaks or changes behavior, resulting in significantly different performance results. It doesn't seem like a high-priority test case to me though. *** Bug 1545732 has been marked as a duplicate of this bug. *** 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-2019:1293 |