qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH v2 0/5] block: Avoid copy-on-read assertions


From: Fam Zheng
Subject: Re: [Qemu-devel] [PATCH v2 0/5] block: Avoid copy-on-read assertions
Date: Wed, 4 Oct 2017 13:39:35 +0800
User-agent: Mutt/1.9.0 (2017-09-02)

On Tue, 10/03 21:22, Eric Blake wrote:
> On 10/03/2017 09:16 PM, address@hidden wrote:
> > Hi,
> > 
> > This series failed automatic build test. Please find the testing commands 
> > and
> > their output below. If you have docker installed, you can probably 
> > reproduce it
> > locally.
> > 
> 
> > 195         [not run] not suitable for this image format: raw
> > 197         - output mismatch (see 197.out.bad)
> > --- /tmp/qemu-test/src/tests/qemu-iotests/197.out   2017-10-04 
> > 01:52:59.000000000 +0000
> > +++ /tmp/qemu-test/build/tests/qemu-iotests/197.out.bad     2017-10-04 
> > 02:15:52.212004491 +0000
> > @@ -12,13 +12,18 @@
> >  128 KiB, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
> >  read 0/0 bytes at offset 0
> >  0 bytes, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
> > -read 2147483136/2147483136 bytes at offset 1024
> > -2 GiB, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
> > +
> > +(process:16284): GLib-ERROR **: gmem.c:100: failed to allocate 2147483136 
> > bytes
> 
> Okay, a test that requires a nearly-2G read in one operation is fringe,
> and I can see it choking 32-bit platforms rather easily.  How do we
> modify the test to not be so mean to memory-starved systems?  And why
> didn't patchew complain about this on v1, which had the same ~2G read?

I don't know. The whole system (Fedora VM) is dedicated to patchew test and no
concurrent task should be running. Maybe 2G is just in between the memory
watermarks.

Fam



reply via email to

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