From mboxrd@z Thu Jan 1 00:00:00 1970 From: Nitesh Narayan Lal Subject: Re: [RFC][Patch v8 0/7] KVM: Guest Free Page Hinting Date: Tue, 12 Feb 2019 12:24:30 -0500 Message-ID: References: <20190204201854.2328-1-nitesh@redhat.com> <286AC319A985734F985F78AFA26841F73DF68060@shsmsx102.ccr.corp.intel.com> <17adc05d-91f9-682b-d9a4-485e6a631422@redhat.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="yNsgkFZEwKifI0Z0GXIZgIb7VVvotZdgH" To: David Hildenbrand , "Wang, Wei W" , "kvm@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "pbonzini@redhat.com" , "lcapitulino@redhat.com" , "pagupta@redhat.com" , "yang.zhang.wz@gmail.com" , "riel@surriel.com" , "mst@redhat.com" , "dodgen@google.com" , "konrad.wilk@oracle.com" , "dhildenb@redhat.com" , "aarcange@redhat.com" Return-path: In-Reply-To: <17adc05d-91f9-682b-d9a4-485e6a631422@redhat.com> Sender: linux-kernel-owner@vger.kernel.org List-Id: kvm.vger.kernel.org This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --yNsgkFZEwKifI0Z0GXIZgIb7VVvotZdgH Content-Type: multipart/mixed; boundary="haeWvAvM7vUbnEC8EgNr9JkZoC03Sn36N"; protected-headers="v1" From: Nitesh Narayan Lal To: David Hildenbrand , "Wang, Wei W" , "kvm@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "pbonzini@redhat.com" , "lcapitulino@redhat.com" , "pagupta@redhat.com" , "yang.zhang.wz@gmail.com" , "riel@surriel.com" , "mst@redhat.com" , "dodgen@google.com" , "konrad.wilk@oracle.com" , "dhildenb@redhat.com" , "aarcange@redhat.com" Message-ID: Subject: Re: [RFC][Patch v8 0/7] KVM: Guest Free Page Hinting References: <20190204201854.2328-1-nitesh@redhat.com> <286AC319A985734F985F78AFA26841F73DF68060@shsmsx102.ccr.corp.intel.com> <17adc05d-91f9-682b-d9a4-485e6a631422@redhat.com> In-Reply-To: <17adc05d-91f9-682b-d9a4-485e6a631422@redhat.com> --haeWvAvM7vUbnEC8EgNr9JkZoC03Sn36N Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US On 2/12/19 4:24 AM, David Hildenbrand wrote: > On 12.02.19 10:03, Wang, Wei W wrote: >> On Tuesday, February 5, 2019 4:19 AM, Nitesh Narayan Lal wrote: >>> The following patch-set proposes an efficient mechanism for handing f= reed >>> memory between the guest and the host. It enables the guests with no = page >>> cache to rapidly free and reclaims memory to and from the host respec= tively. >>> >>> Benefit: >>> With this patch-series, in our test-case, executed on a single system= and >>> single NUMA node with 15GB memory, we were able to successfully launc= h >>> atleast 5 guests when page hinting was enabled and 3 without it. (Det= ailed >>> explanation of the test procedure is provided at the bottom). >>> >>> Changelog in V8: >>> In this patch-series, the earlier approach [1] which was used to capt= ure and >>> scan the pages freed by the guest has been changed. The new approach = is >>> briefly described below: >>> >>> The patch-set still leverages the existing arch_free_page() to add th= is >>> functionality. It maintains a per CPU array which is used to store th= e pages >>> freed by the guest. The maximum number of entries which it can hold i= s >>> defined by MAX_FGPT_ENTRIES(1000). When the array is completely fille= d, it >>> is scanned and only the pages which are available in the buddy are st= ored. >>> This process continues until the array is filled with pages which are= part of >>> the buddy free list. After which it wakes up a kernel per-cpu-thread.= >>> This kernel per-cpu-thread rescans the per-cpu-array for any re-alloc= ation >>> and if the page is not reallocated and present in the buddy, the kern= el >>> thread attempts to isolate it from the buddy. If it is successfully i= solated, the >>> page is added to another per-cpu array. Once the entire scanning proc= ess is >>> complete, all the isolated pages are reported to the host through an = existing >>> virtio-balloon driver. >> Hi Nitesh, >> >> Have you guys thought about something like below, which would be simpl= er: > Responding because I'm the first to stumble over this mail, hah! :) > >> - use bitmaps to record free pages, e.g. xbitmap: https://lkml.org/lkm= l/2018/1/9/304. >> The bitmap can be indexed by the guest pfn, and it's globally access= ed by all the CPUs; > Global means all VCPUs will be competing potentially for a single lock > when freeing/allocating a page, no? What if you have 64VCPUs > allocating/freeing memory like crazy? > > (I assume some kind of locking is required even if the bitmap would be > atomic. Also, doesn't xbitmap mean that we eventually have to allocate > memory at places where we don't want to - e.g. from arch_free_page ?) > > That's the big benefit of taking the pages of the buddy free list. Othe= r > VCPUs won't stumble over them, waiting for them to get freed in the > hypervisor. > >> - arch_free_page(): set the bits of the freed pages from the bitmap >> (no per-CPU array with hardcoded fixed length and no per-cpu scanning= thread) >> - arch_alloc_page(): clear the related bits from the bitmap >> - expose 2 APIs for the callers: >> -- unsigned long get_free_page_hints(unsigned long pfn_start, unsign= ed int nr);=20 >> This API searches for the next free page chunk (@nr of pages), st= arting from @pfn_start. >> Bits of those free pages will be cleared after this function retu= rns. >> -- void put_free_page_hints(unsigned long pfn_start, unsigned int nr= ); >> This API sets the @nr continuous bits starting from pfn_start. >> >> Usage example with balloon: >> 1) host requests to start ballooning; >> 2) balloon driver get_free_page_hints and report the hints to host via= report_vq; >> 3) host calls madvise(pfn_start, DONTNEED) for each reported chunk of = free pages and put back pfn_start to ack_vq; >> 4) balloon driver receives pfn_start and calls put_free_page_hints(pfn= _start) to have the related bits from the bitmap to be set, indicating th= at those free pages are ready to be allocated. > This sounds more like "the host requests to get free pages once in a > while" compared to "the host is always informed about free pages". At > the time where the host actually has to ask the guest (e.g. because the= > host is low on memory), it might be to late to wait for guest action. > Nitesh uses MADV_FREE here (as far as I recall :) ), to only mark pages= > as candidates for removal and if the host is low on memory, only > scanning the guest page tables is sufficient to free up memory. > > But both points might just be an implementation detail in the example > you describe. > >> In above 2), get_free_page_hints clears the bits which indicates that = those pages are not ready to be used by the guest yet. Why? >> This is because 3) will unmap the underlying physical pages from EPT. = Normally, when guest re-visits those pages, EPT violations and QEMU page = faults will get a new host page to set up the related EPT entry. If guest= uses that page before the page gets unmapped (i.e. right before step 3),= no EPT violation happens and the guest will use the same physical page t= hat will be unmapped and given to other host threads. So we need to make = sure that the guest free page is usable only after step 3 finishes. >> >> Back to arch_alloc_page(), it needs to check if the allocated pages ha= ve "1" set in the bitmap, if that's true, just clear the bits. Otherwise,= it means step 2) above has happened and step 4) hasn't been reached. In = this case, we can either have arch_alloc_page() busywaiting a bit till 4)= is done for that page >> Or better to have a balloon callback which prioritize 3) and 4) to mak= e this page usable by the guest. > Regarding the latter, the VCPU allocating a page cannot do anything if > the page (along with other pages) is just being freed by the hypervisor= =2E > It has to busy-wait, no chance to prioritize. > >> Using bitmaps to record free page hints don't need to take the free pa= ges off the buddy list and return them later, which needs to go through t= he long allocation/free code path. >> > Yes, but it means that any process is able to get stuck on such a page > for as long as it takes to report the free pages to the hypervisor and > for it to call madvise(pfn_start, DONTNEED) on any such page. > > Nice idea, but I think we definitely need something the can potentially= > be implemented per-cpu without any global locks involved. > > Thanks! > >> Best, >> Wei >> Hi Wei, For your comment, I agree with David. If we have one global per-cpu, we will have to acquire a lock. Also as David mentioned the idea is to derive the hints from the guest, rather than host asking for free pages. However, I am wondering if having per-cpu bitmaps is possible? Using this I can possibly get rid of the fixed array size issue. --=20 Regards Nitesh --haeWvAvM7vUbnEC8EgNr9JkZoC03Sn36N-- --yNsgkFZEwKifI0Z0GXIZgIb7VVvotZdgH Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEkXcoRVGaqvbHPuAGo4ZA3AYyozkFAlxjAU4ACgkQo4ZA3AYy ozmYxA/+KEd6b+8QmF5vsn8gZZN0sGR63uNYm7B/UXPo8nD/wSM30YXm7CsaHPDp tcSfI7SJ4NPc0fpv8wDidXVKUWbaLQ8J5lvtXi98DA0oOmyhJkipIEcvR5yq2S4x FQSgpWxa/WDj+Lu5ocu4BLgQStfAS6ilw8Jbfm8pNavhtcJN4umpo6iAlVXBJUsb bXY1jwdw1ShAJxG+JLtEHuPClFzY/WcuMOIuY5J5YxhPqI50nP9Q4QJ6S3FC0roq +2lBGdCy5NA/7jPHejf8CFthyTv97q7vu9dU66jHNI8KTTYwe+FEiwqUiicBfaQQ NE6t5ACkYT5gRQNMqLBhk4yhYRkvCDZgdukoTmjqa6Vf0Y7WAbVG9ZXT5vte40ou E/jy+ETMVyOUikEmfq1jQwDqNc+LrwSJiWg+//t8OrjgFWZJ/iG7rczZzscoei41 jnGWKM30BEE1XvyGmTtO0L/XN8BzK7jyxP+hizqPK9I8qqKfd/LpqKoloxt4oU+u QnYC4C+zJCbcPmyVw/4kwnyvKIoFXP1DzZYeW0Yn2wbLPAkfLUg2WpwqbbN+rGNS Fs/ieT0WL+vg7VRMfLIZZXdQwapErrMRawpxcQUhHhPE0rb2PDUPKivBkFg+IOtB rLIFvfjOqAiBLtMAR8QszWnTPU6EhnBU4vxCeblerGUcVRHyUQg= =FAWY -----END PGP SIGNATURE----- --yNsgkFZEwKifI0Z0GXIZgIb7VVvotZdgH--