<div dir="auto"><div><br><div class="gmail_extra"><br><div class="gmail_quote">On Nov 30, 2016 4:48 PM, "Ben England" <<a href="mailto:bengland@redhat.com">bengland@redhat.com</a>> wrote:<br type="attribution"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I uploaded the article to:<br>
<br>
<a href="https://s3.amazonaws.com/ben.england/rhev-vm-rsptime.pdf" rel="noreferrer" target="_blank">https://s3.amazonaws.com/ben.<wbr>england/rhev-vm-rsptime.pdf</a><br>
<br>
I had just gone to work for Red Hat back in 2011 so I made the mistake of including a company-internal URL in a public-facing document. We can update the bz with the above link if you want. This article is ANCIENT (2011), so while the basic approach should still be relevant, some of the specifics may have changed. This was a RHEV-on-NFS configuration.<br>
<br>
As for why dirty ratio lowering is not part of a tuned profile, there is a debate in the performance team about dirty ratio, with some advocating for higher dirty ratios that help some application workloads (example: writing /tmp files). I'd stand by this article for the particular configuration that was being studied though, and I think the basic approach of controlling latency and improving fairness by managing queue depths is very relevant today.<br>
<br>
cc'ed Sanjay Rao, who continues to be a RHEV expert in the perf team (I no longer am working on it).<br></blockquote></div></div></div><div dir="auto"><br></div><div dir="auto">Ben, any idea why, at the time, you have added a workload from the host, that was competing with the VMs? </div><div dir="auto">Usually the only IO load from the hosts are the logs... Nothing serious really. </div><div dir="auto">Y. </div><div dir="auto"><br></div><div dir="auto"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<font color="#888888"><br>
-ben<br>
</font><div class="elided-text"><br>
<br>
----- Original Message -----<br>
> From: "Martin Polednik" <<a href="mailto:mpolednik@redhat.com">mpolednik@redhat.com</a>><br>
> To: "Sven Kieske" <<a href="mailto:s.kieske@mittwald.de">s.kieske@mittwald.de</a>><br>
> Cc: <a href="mailto:devel@ovirt.org">devel@ovirt.org</a>, "Ben" <<a href="mailto:bengland@redhat.com">bengland@redhat.com</a>><br>
> Sent: Wednesday, November 30, 2016 7:22:05 AM<br>
> Subject: Re: VDSM changes Linux memory dirty ratios - why?<br>
><br>
> On 30/11/16 13:10 +0100, Sven Kieske wrote:<br>
> >On 30/11/16 08:48, Martin Polednik wrote:<br>
> >> It's not really irrelevant, the host still uses disk cache. Anyway,<br>
> >> there is BZ[1] with a presentation[2] that (imho reasonably) states:<br>
> >><br>
> >> "Reduce dirty page limits in KVM host to allow<br>
> >> direct I/O writer VMs to compete successfully<br>
> >> with buffered writer processes for storage<br>
> >> access"<br>
> >><br>
> >> I wonder why virtual-host tuned profile doesn't contain these values:<br>
> >><br>
> >> $ grep vm.dirty /usr/lib/tuned/virtual-host/<wbr>tuned.conf<br>
> >> vm.dirty_background_ratio = 5<br>
> >><br>
> >> [1]<a href="https://bugzilla.redhat.com/show_bug.cgi?id=740887" rel="noreferrer" target="_blank">https://bugzilla.redhat.<wbr>com/show_bug.cgi?id=740887</a><br>
> >> [2]<a href="http://perf1.lab.bos.redhat.com/bengland/laptop/rhev/rhev-vm-rsptime.pdf" rel="noreferrer" target="_blank">http://perf1.lab.bos.<wbr>redhat.com/bengland/laptop/<wbr>rhev/rhev-vm-rsptime.pdf</a><br>
> ><br>
> >Could you share [2] with the wider community? This would be awesome!<br>
><br>
> Sorry, I've totally missed the fact it's internal link (unfortunately<br>
> publicly visible on the BZ). I believe it's slightly outdated, but<br>
> let's ask the author.<br>
><br>
> Ben, is the document[2] somehow still valid and could it be made publicly<br>
> available?<br>
><br>
> Re-referencing for completeness:<br>
> [2]<a href="http://perf1.lab.bos.redhat.com/bengland/laptop/rhev/rhev-vm-rsptime.pdf" rel="noreferrer" target="_blank">http://perf1.lab.bos.<wbr>redhat.com/bengland/laptop/<wbr>rhev/rhev-vm-rsptime.pdf</a><br>
><br>
> >--<br>
> >Mit freundlichen Grüßen / Regards<br>
> ><br>
> >Sven Kieske<br>
> ><br>
> >Systemadministrator<br>
> >Mittwald CM Service GmbH & Co. KG<br>
> >Königsberger Straße 6<br>
> >32339 Espelkamp<br>
> >T: <a href="tel:%2B495772%20293100" value="+495772293100">+495772 293100</a><br>
> >F: <a href="tel:%2B495772%20293333" value="+495772293333">+495772 293333</a><br>
> ><a href="https://www.mittwald.de" rel="noreferrer" target="_blank">https://www.mittwald.de</a><br>
> >Geschäftsführer: Robert Meyer<br>
> >St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen<br>
> >Komplementärin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen<br>
> ><br>
><br>
><br>
><br>
><br>
> >_____________________________<wbr>__________________<br>
> >Devel mailing list<br>
> ><a href="mailto:Devel@ovirt.org">Devel@ovirt.org</a><br>
> ><a href="http://lists.ovirt.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.ovirt.org/<wbr>mailman/listinfo/devel</a><br>
><br>
><br>
______________________________<wbr>_________________<br>
Devel mailing list<br>
<a href="mailto:Devel@ovirt.org">Devel@ovirt.org</a><br>
<a href="http://lists.ovirt.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.ovirt.org/<wbr>mailman/listinfo/devel</a></div></blockquote></div><br></div></div></div>