From mboxrd@z Thu Jan 1 00:00:00 1970 From: Nitesh Narayan Lal Subject: Re: [RFC][Patch v8 6/7] KVM: Enables the kernel to isolate and report free pages Date: Tue, 12 Feb 2019 12:10:52 -0500 Message-ID: <941fc3c3-e38d-a744-5d4a-94a63c6ad62e@redhat.com> References: <20190204201854.2328-7-nitesh@redhat.com> <20190205153607-mutt-send-email-mst@kernel.org> <20190205165514-mutt-send-email-mst@kernel.org> <20190208163601-mutt-send-email-mst@kernel.org> <20190209192104-mutt-send-email-mst@kernel.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="7J8ManGoh82i3G7TWYecVQdqYvIjZDxYF" Cc: kvm list , LKML , Paolo Bonzini , lcapitulino@redhat.com, pagupta@redhat.com, wei.w.wang@intel.com, Yang Zhang , Rik van Riel , david@redhat.com, dodgen@google.com, Konrad Rzeszutek Wilk , dhildenb@redhat.com, Andrea Arcangeli To: "Michael S. Tsirkin" , Alexander Duyck Return-path: In-Reply-To: <20190209192104-mutt-send-email-mst@kernel.org> Sender: linux-kernel-owner@vger.kernel.org List-Id: kvm.vger.kernel.org This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --7J8ManGoh82i3G7TWYecVQdqYvIjZDxYF Content-Type: multipart/mixed; boundary="LGoU5OqJvrWR8z2fPxS0Q9CW28nUTKijU"; protected-headers="v1" From: Nitesh Narayan Lal To: "Michael S. Tsirkin" , Alexander Duyck Cc: kvm list , LKML , Paolo Bonzini , lcapitulino@redhat.com, pagupta@redhat.com, wei.w.wang@intel.com, Yang Zhang , Rik van Riel , david@redhat.com, dodgen@google.com, Konrad Rzeszutek Wilk , dhildenb@redhat.com, Andrea Arcangeli Message-ID: <941fc3c3-e38d-a744-5d4a-94a63c6ad62e@redhat.com> Subject: Re: [RFC][Patch v8 6/7] KVM: Enables the kernel to isolate and report free pages References: <20190204201854.2328-7-nitesh@redhat.com> <20190205153607-mutt-send-email-mst@kernel.org> <20190205165514-mutt-send-email-mst@kernel.org> <20190208163601-mutt-send-email-mst@kernel.org> <20190209192104-mutt-send-email-mst@kernel.org> In-Reply-To: <20190209192104-mutt-send-email-mst@kernel.org> --LGoU5OqJvrWR8z2fPxS0Q9CW28nUTKijU Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US On 2/9/19 7:38 PM, Michael S. Tsirkin wrote: > On Fri, Feb 08, 2019 at 02:05:09PM -0800, Alexander Duyck wrote: >> On Fri, Feb 8, 2019 at 1:38 PM Michael S. Tsirkin wro= te: >>> On Fri, Feb 08, 2019 at 03:41:55PM -0500, Nitesh Narayan Lal wrote: >>>>>> I am also planning to try Michael's suggestion of using MAX_ORDER = - 1. >>>>>> However I am still thinking about a workload which I can use to te= st its >>>>>> effectiveness. >>>>> You might want to look at doing something like min(MAX_ORDER - 1, >>>>> HUGETLB_PAGE_ORDER). I know for x86 a 2MB page is the upper limit f= or >>>>> THP which is the most likely to be used page size with the guest. >>>> Sure, thanks for the suggestion. >>> Given current hinting in balloon is MAX_ORDER I'd say >>> share code. If you feel a need to adjust down the road, >>> adjust both of them with actual testing showing gains. >> Actually I'm left kind of wondering why we are even going through >> virtio-balloon for this? > Just look at what does it do. > > It improves memory overcommit if guests are cooperative, and it does > this by giving the hypervisor addresses of pages which it can discard. > > It's just *exactly* like the balloon with all the same limitations. > >> It seems like this would make much more sense >> as core functionality of KVM itself for the specific architectures >> rather than some side thing. > Well same as balloon: whether it's useful to you at all > would very much depend on your workloads. > > This kind of cooperative functionality is good for co-located > single-tenant VMs. That's pretty niche. The core things in KVM > generally don't trust guests. > > >> In addition this could end up being >> redundant when you start getting into either the s390 or PowerPC >> architectures as they already have means of providing unused page >> hints. > Interesting. Is there host support in kvm? > > >> I have a set of patches I proposed that add similar functionality via >> a KVM hypercall for x86 instead of doing it as a part of a Virtio >> device[1]. I'm suspecting the overhead of doing things this way is >> much less then having to make multiple madvise system calls from QEMU >> back into the kernel. > Well whether it's a virtio device is orthogonal to whether it's an > madvise call, right? You can build vhost-pagehint and that can > handle requests in a VQ within balloon and do it > within host kernel directly. > > virtio rings let you pass multiple pages so it's really hard to > say which will win outright - maybe it's more important > to coalesce exits. > > Nitesh, how about trying same tests and reporting performance? Noted, I can give it a try before my next positing. > > >> One other concern that has been pointed out with my patchset that >> would likely need to be addressed here as well is what do we do about >> other hypervisors that decide to implement page hinting. We probably >> should look at making this KVM/QEMU specific code run through the >> paravirtual infrastructure instead of trying into the x86 arch code >> directly. >> >> [1] https://lkml.org/lkml/2019/2/4/903 > > So virtio is a paravirtual interface, that's an argument for > using it then. > > In any case pls copy the Cc'd crowd on future version of your patches. > --=20 Regards Nitesh --LGoU5OqJvrWR8z2fPxS0Q9CW28nUTKijU-- --7J8ManGoh82i3G7TWYecVQdqYvIjZDxYF Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEkXcoRVGaqvbHPuAGo4ZA3AYyozkFAlxi/hwACgkQo4ZA3AYy ozm79g//UvTPI4aVhIteaZHs3qkezYTAZa/qjveQePvFwZwxnL2zPu28xPUOU0E1 rsobZJYN8xSLDqRdje2p3eJZHx03ChNT9cRO3XhMWRdHLqnBQ7gt0SJFPd+qWEf+ YpLUjlWVC4kepIeEKlaPvFlGQ8sXDdc9OX6aTrIccmXsD2F7wOYVldlAT5qoZ+K9 lzKugk3gAesdlTJSAoGy2aaQ3MEAFCpqGgDpmHIOU2za9AAPLL3PUBpwC5PVtPtb wgMc5yYebCWxDTICWupYjcw+yceNkF0Es829r5ivPwk1DKEMrPK98piv9+8jjvWj XgflFyfrHiU1tUpdhLkmLk+bZIkhxigHwAUBNY6Kdh6OAN11kgBQgsDh0FSDbXcC l/EMrv2Pnktw9VfcsoABO43Y42FHZN8qLkKmq+re4YwkHy2QgVilBR2uNbSzDNrM J1xig2TTMs652QED4DLa/+7r71ceoP9WImtWuH8OGSkZan2ybInOC07fR2/QL7+m 9NUss4eSes3u95470h5jUh9D1yVrwwT6Vz8+t91XHZc7K6AfGEezo653A6ekH6pl ZvHa0WJ0ZBNkZnEFH/G68Yegm3/ZO9Wph6v+O9lWKjTD1uNL3GFZU/1+Je6XtMHJ 3PXiummtTXTgPpZdO7VOCFhLJGeTug7T9GTVSCf6wYhaMaquEqE= =E0SH -----END PGP SIGNATURE----- --7J8ManGoh82i3G7TWYecVQdqYvIjZDxYF--