On Tue, Sep 22, 2015 at 01:01:03PM +0200, Marc-André Lureau wrote:
> Hi
>
> On Tue, Sep 22, 2015 at 12:12 PM, Michael S. Tsirkin <m...@redhat.com> wrote:
> >> 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.
> >
>
> I failed to see how the log of other devices is being updated when one
> device needs a resize. There are multiple log already in this case.
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.
> >> 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.
> --
> Marc-André Lureau
