[ovirt-devel] VDSM changes Linux memory dirty ratios - why?

[Yaniv Kaul]

On Wed, Nov 30, 2016 at 2:11 PM, Sven Kieske <s.kieske at mittwald.de> wrote:

> On 30/11/16 09:13, Yaniv Kaul wrote:
> > Thanks, but it really makes no sense to me. The direct IO by the VMs is
> > going to a different storage than what the host is writing to, in most
> > cases.
> > The host would write to the local disk, the VMs - to a shared storage,
> > across NFS or block layer or so. Moreover, their IO is not buffered.
> > There is very little IO coming from the host itself, generally (I hope
> > so!).
> >
> > Partially unrelated - the trend today is actually to put NOOP on the VMs
> -
> > the deadline is quite meaningless, as the host scheduler will reschedule
> > anyway as it see fits.
> > Most likely it is also a deadline scheduler (but could be NOOP as well if
> > it's an all flash array, for example). Therefore there is no reason for
> > anything but simple NOOP on the VMs themselves.
> >
> > In short, I think it's an outdated decision that perhaps should be
> > revisited. Not urgent, though.
> > Y.
>
> I know it's not the most cared about usecase
> but I'd like to add that this might affect local storage
> domains, which I happen to use a lot, and maybe others too.
>

In which case we should change the default for local storage.
BTW, when using Gluster, they have returned these values to the original
values...
Y.


> --
> Mit freundlichen Grüßen / Regards
>
> Sven Kieske
>
> Systemadministrator
> Mittwald CM Service GmbH & Co. KG
> Königsberger Straße 6
> 32339 Espelkamp
> T: +495772 293100
> F: +495772 293333
> https://www.mittwald.de
> Geschäftsführer: Robert Meyer
> St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen
> Komplementärin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen
>
>
> _______________________________________________
> Devel mailing list
> Devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/devel/attachments/20161130/eaa9ac88/attachment-0001.html>