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. >> 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? > 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). -- Marc-André Lureau
