From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:60373)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <mst@redhat.com>) id 1ZeKYl-0006g2-Kn
	for qemu-devel@nongnu.org; Tue, 22 Sep 2015 06:12:28 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <mst@redhat.com>) id 1ZeKYh-0002q8-FG
	for qemu-devel@nongnu.org; Tue, 22 Sep 2015 06:12:27 -0400
Received: from mx1.redhat.com ([209.132.183.28]:52450)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <mst@redhat.com>) id 1ZeKYh-0002pc-Ah
	for qemu-devel@nongnu.org; Tue, 22 Sep 2015 06:12:23 -0400
Date: Tue, 22 Sep 2015 13:12:18 +0300
From: "Michael S. Tsirkin" <mst@redhat.com>
Message-ID: <20150922101218.GA19649@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>
	<CAJ+F1CL+OvNFadaCACwgp7KYWVi7b6=9v5cDUDN9R8wVJ84XcQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
In-Reply-To: <CAJ+F1CL+OvNFadaCACwgp7KYWVi7b6=9v5cDUDN9R8wVJ84XcQ@mail.gmail.com>
Content-Transfer-Encoding: quoted-printable
Subject: Re: [Qemu-devel] [PATCH v4 07/22] vhost: alloc shareable log
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: =?iso-8859-1?Q?Marc-Andr=E9?= Lureau <marcandre.lureau@gmail.com>
Cc: thibaut collet <thibaut.collet@6wind.com>, Jason Wang <jasowang@redhat.com>, Paolo Bonzini <pbonzini@redhat.com>, haifeng lin <haifeng.lin@huawei.com>, QEMU <qemu-devel@nongnu.org>

On Mon, Sep 21, 2015 at 11:44:38PM +0200, Marc-Andr=E9 Lureau wrote:
> Hi
>=20
> On Mon, Sep 21, 2015 at 9:29 PM, Michael S. Tsirkin <mst@redhat.com> wr=
ote:
> >> Can this be considered a future enhancement?
> >
> > What's the big issue? Just count the devices that need a shared one, =
if
> > that count is 0 reallocate with shared =3D=3D false.
>=20
>=20
> But then it should also VHOST_SET_LOG_BASE all the other devices with
> the new log, unless you want to tackle only the future log users. So
> it needs to track all the users of the log.

We already do this.
Same applies to non-memfd->memfd switch.

> Is there a clear benefit
> of this? since the memory isn't shared without the memfd passed to
> 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.

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.

> --=20
> Marc-Andr=E9 Lureau