From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:33233) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZeM9T-0002hD-1B for qemu-devel@nongnu.org; Tue, 22 Sep 2015 07:54:27 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZeM9S-0007Dc-29 for qemu-devel@nongnu.org; Tue, 22 Sep 2015 07:54:26 -0400 Received: from mx1.redhat.com ([209.132.183.28]:39553) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZeM9R-0007DS-TC for qemu-devel@nongnu.org; Tue, 22 Sep 2015 07:54:25 -0400 Date: Tue, 22 Sep 2015 14:54:21 +0300 From: "Michael S. Tsirkin" Message-ID: <20150922145342-mutt-send-email-mst@redhat.com> References: <1442657533-13030-1-git-send-email-marcandre.lureau@redhat.com> <1442657533-13030-8-git-send-email-marcandre.lureau@redhat.com> <20150921113812-mutt-send-email-mst@redhat.com> <2063208980.14557622.1442844122026.JavaMail.zimbra@redhat.com> <20150921222715-mutt-send-email-mst@redhat.com> <20150922101218.GA19649@redhat.com> <20150922143004-mutt-send-email-mst@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH v4 07/22] vhost: alloc shareable log List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: =?iso-8859-1?Q?Marc-Andr=E9?= Lureau Cc: thibaut collet , Jason Wang , Paolo Bonzini , haifeng lin , QEMU On Tue, Sep 22, 2015 at 01:50:47PM +0200, Marc-Andr=E9 Lureau wrote: > hi >=20 > On Tue, Sep 22, 2015 at 1:41 PM, Michael S. Tsirkin wr= ote: > > There's a single log at the moment: > > static struct vhost_log *vhost_log; > > > > But all devices are updated by the memory core, we don't > > have a list in the vhost code. >=20 > Do you mean that all devices will have their memory listener restart > the log, so they all point to the same global vhost_log? Exactly. > >> >> Is there a clear benefit > >> >> of this? since the memory isn't shared without the memfd passed t= o > >> >> another process and the overhead of memfd is probably quite small= , and > >> >> pre-shm or future resize will not use the shared memory already. > >> > > >> > For example, THP doesn't work for memfd at the moment, > >> > so all accesses are a bit slower. > >> > >> What's THP? How is it slower once the fd is mmap? > > > > Transparent huge page. This process doesn't work for > > memfd AFAIK. > > > >> > Really, I don't want to merge hacks. Switching from non memfd > >> > to memfd but not back has all the signs of one. > >> > Let's do it cleanly please. > >> > >> The current code isn't switching existing logs either. What would be > >> simpler to do is to allocate a different log region for the "share" > >> case. So there would be no need to switch other non-shareable logs (= to > >> the cost of using twice the memory needed). > > > > OK, that's not too bad. Let's go for it. >=20 >=20 > ok, working on new patch I've tentatively applied the multiqueue patches, please make sure yours work on top. > --=20 > Marc-Andr=E9 Lureau