qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PULL 42/57] Page request: Consume pages off the post-c


From: Markus Armbruster
Subject: Re: [Qemu-devel] [PULL 42/57] Page request: Consume pages off the post-copy queue
Date: Thu, 12 Nov 2015 14:36:46 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux)

Peter Maydell <address@hidden> writes:

> On 12 November 2015 at 12:04, Dr. David Alan Gilbert
> <address@hidden> wrote:
>> * Peter Maydell (address@hidden) wrote:
>>> On 10 November 2015 at 14:25, Juan Quintela <address@hidden> wrote:
>>> > From: "Dr. David Alan Gilbert" <address@hidden>
>>> >
>>> > When transmitting RAM pages, consume pages that have been queued by
>>> > MIG_RPCOMM_REQPAGE commands and send them ahead of normal page scanning.
>>> >
>>> > Note:
>>> >   a) After a queued page the linear walk carries on from after the
>>> > unqueued page; there is a reasonable chance that the destination
>>> > was about to ask for other closeby pages anyway.
>>> >
>>> >   b) We have to be careful of any assumptions that the page walking
>>> > code makes, in particular it does some short cuts on its first linear
>>> > walk that break as soon as we do a queued page.
>>> >
>>> >   c) We have to be careful to not break up host-page size chunks, since
>>> > this makes it harder to place the pages on the destination.
>>> >
>>> > Signed-off-by: Dr. David Alan Gilbert <address@hidden>
>>> > Reviewed-by: Juan Quintela <address@hidden>
>>> > Signed-off-by: Juan Quintela <address@hidden>
>>>
>>> I've just discovered that this is causing 'make check' failures on
>>> my OSX host (unfortunately something in my setup is causing
>>> 'make check' failures to not always cause a build failure, so I
>>> didn't notice earlier):
>>
>> It's only failing on OSX? Every time or only sometimes?
>
> Only OSX, and always. I think OSX is pickier about mutexes really
> needing to be initialized before use.
>
>> If you can find a way to get a backtrace off that qemu_mutex_lock case
>> that would be great; I'd assume the later errors are the fall out from that.
>
> I'll have a look after lunch, but it's usually painful to get a
> backtrace out of this kind of qtest, because it's clearly starting
> a whole pile of QEMUs and there's no way I know of to say "only
> run a few of these tests, not the whole huge pile".

Not sure this helps, but here goes anyway: run the make with V=1, fish
out the gtester line, add -p /name/of/the/test.  Here's an example from
my shell history:

    $ MALLOC_PERTURB_=${MALLOC_PERTURB_:-$((RANDOM % 255 + 1))} gtester -k 
--verbose -m=quick -p /dicts/large_dict tests/check-qjson



reply via email to

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