On Thu, Sep 01, 2016 at 06:52:42PM +0200, Michal Privoznik wrote: > On 01.09.2016 17:10, Eduardo Habkost wrote: > > On Wed, Aug 31, 2016 at 02:47:21PM -0700, > > no-re...@ec2-52-6-146-230.compute-1.amazonaws.com wrote: > > [...] > >> GTESTER check-qtest-x86_64 > >> qemu-system-x86_64: Failed initializing vhost-user memory map, consider > >> using -object memory-backend-file share=on > >> qemu-system-x86_64: vhost_set_mem_table failed: Success (0) > > [...] > >> ** > >> ERROR:/tmp/qemu-test/src/tests/vhost-user-test.c:149:wait_for_fds: > >> assertion failed: (s->fds_num) > > > > Ouch. It looks like the ordering requirements are messier than I > > thought. vhost-user depends on the memory backends to be already > > initialized. > > > > We can't use early initialization because prealloc delays chardev > > init too much. We can't delay initialization because it is done > > after netdevs. > > > > We _really_ need to change this to simply use the ordering used > > on the command-line/config instead of hardcoding messy ordering > > requirements, but I wouldn't like to wait for a QemuOpts > > refactoring to fix the bug. I will take a look at the memory > > regions initialization path, and try to trigger the > > memory-backend prealloc code there. > > > > What I don't understand here is, if kernel already has a pool of > hugepages from which qemu tries to allocate some, why does allocation > take up to 1 minute? I would understand if it was during building of the > pool, but once those pages are reserved allocating them should take no > time. Isn't this a problem in kernel (too)?
I believe the pages are reserved, but are zeroed when actually allocated by userspace. -- Eduardo
