From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:52198) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aqgFM-0001jJ-7j for qemu-devel@nongnu.org; Thu, 14 Apr 2016 08:19:45 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aqgFH-0000uj-75 for qemu-devel@nongnu.org; Thu, 14 Apr 2016 08:19:44 -0400 Received: from mx1.redhat.com ([209.132.183.28]:54679) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aqgFH-0000tm-25 for qemu-devel@nongnu.org; Thu, 14 Apr 2016 08:19:39 -0400 References: <1460548364-27469-1-git-send-email-thuth@redhat.com> <20160413145835-mutt-send-email-mst@redhat.com> <570E5D05.2030507@redhat.com> <20160414114757.GE2252@work-vm> From: Thomas Huth Message-ID: <570F8AD5.4040805@redhat.com> Date: Thu, 14 Apr 2016 14:19:33 +0200 MIME-Version: 1.0 In-Reply-To: <20160414114757.GE2252@work-vm> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH] hw/virtio/balloon: Fixes for different host page sizes List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Dr. David Alan Gilbert" Cc: "Michael S. Tsirkin" , qemu-devel@nongnu.org, dgibson@redhat.com, wehuang@redhat.com, drjones@redhat.com, amit.shah@redhat.com, jitendra.kolhe@hpe.com On 14.04.2016 13:47, Dr. David Alan Gilbert wrote: > * Thomas Huth (thuth@redhat.com) wrote: >=20 >> That would mean a regression compared to what we have today. Currently= , >> the ballooning is working OK for 64k guests on a 64k ppc host - rather >> by chance than on purpose, but it's working. The guest is always sendi= ng >> all the 4k fragments of a 64k page, and QEMU is trying to call madvise= () >> for every one of them, but the kernel is ignoring madvise() on >> non-64k-aligned addresses, so we end up with a situation where the >> madvise() frees a whole 64k page which is also declared as free by the >> guest. >=20 > I wouldn't worry about migrating your fragmenet map; but I wonder if it > needs to be that complex - does the guest normally do something more sa= ne > like do the 4k pages in order and so you've just got to track the last > page it tried rather than having a full map? That's maybe a little bit easier and might work for well-known Linux guests, but IMHO it's even more a hack than my approach: If the Linux driver one day is switched to send the pages in the opposite order, or if somebody tries to run a non-wellknown (i.e. non-Linux) guest, this does not work at all anymore. > A side question is whether the behaviour that's seen by virtio_ballon_h= andle_output > is always actually the full 64k page; it calls balloon_page once > for each message/element - but if all of those elements add back up to = the full > page, perhaps it makes more sense to reassemble it there? That might work for 64k page size guests ... but for 4k guests, I think you'll have a hard time to reassemble a page there more easily than with my current approach. Or do you have a clever algorithm in mind that could do the job well there? Thomas