From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Michael S. Tsirkin" Subject: Re: [PATCH] Add a page cache-backed balloon device driver. Date: Wed, 27 Jun 2012 12:04:10 +0300 Message-ID: <20120627090410.GB17507@redhat.com> References: <1340742778-11282-1-git-send-email-fes@google.com> <4FEA1E2E.4020806@redhat.com> <4FEA2D85.60002@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Return-path: Content-Disposition: inline In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: virtualization-bounces@lists.linux-foundation.org Errors-To: virtualization-bounces@lists.linux-foundation.org To: Frank Swiderski Cc: Andrea Arcangeli , Rik van Riel , Rafael Aquini , kvm@vger.kernel.org, linux-kernel@vger.kernel.org, virtualization@lists.linux-foundation.org, Ying Han , mikew@google.com List-Id: virtualization@lists.linuxfoundation.org On Tue, Jun 26, 2012 at 04:45:36PM -0700, Frank Swiderski wrote: > On Tue, Jun 26, 2012 at 2:45 PM, Rik van Riel wrote: > > On 06/26/2012 05:31 PM, Frank Swiderski wrote: > >> > >> On Tue, Jun 26, 2012 at 1:40 PM, Rik van Riel =A0wrot= e: > > > > > >>> The code looks good to me, my only worry is the > >>> code duplication. We now have 5 balloon drivers, > >>> for 4 hypervisors, all implementing everything > >>> from scratch... > >> > >> > >> Do you have any recommendations on this? =A0I could (I think reasonably > >> so) modify the existing virtio_balloon.c and have it change behavior > >> based on a feature bit or other configuration. =A0I'm not sure that > >> really addresses the root of what you're pointing out--it's still > >> adding a different implementation, but doing so as an extension of an > >> existing one. > > > > > > Ideally, I believe we would have two balloon > > top parts in a guest (one classical balloon, > > one on the LRU), and four bottom parts (kvm, > > xen, vmware & s390). > > > > That way the virt specific bits of a balloon > > driver would be essentially a ->balloon_page > > and ->release_page callback for pages, as well > > as methods to communicate with the host. > > > > All the management of pages, including stuff > > like putting them on the LRU, or isolating > > them for migration, would be done with the > > same common code, regardless of what virt > > software we are running on. > > > > Of course, that is a substantial amount of > > work and I feel it would be unreasonable to > > block anyone's code on that kind of thing > > (especially considering that your code is good), > > but I do believe the explosion of balloon > > code is a little worrying. > > > = > Hm, that makes a lot of sense. That would be a few patches definitely > worth doing, IMHO. I'm not entirely sure how I feel about inflating > the balloon drivers in the meantime. Sigh, and I didn't even mean > that as a pun. > = > fes Actually I'm not 100% sure the num_pages interface of the classical balloon is a good fit for the LRU balloon. Let's figure that out first: if we fork the interface there might not be all that much common code ... -- = MST