qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH v4 07/22] vhost: alloc shareable log


From: Michael S. Tsirkin
Subject: Re: [Qemu-devel] [PATCH v4 07/22] vhost: alloc shareable log
Date: Tue, 22 Sep 2015 14:54:21 +0300

On Tue, Sep 22, 2015 at 01:50:47PM +0200, Marc-André Lureau wrote:
> hi
> 
> On Tue, Sep 22, 2015 at 1:41 PM, Michael S. Tsirkin <address@hidden> wrote:
> > 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.
> 
> 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 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.
> >>
> >> 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.
> 
> 
> ok, working on new patch

I've tentatively applied the multiqueue patches, please make sure
yours work on top.

> -- 
> Marc-André Lureau



reply via email to

[Prev in Thread] Current Thread [Next in Thread]