qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] the qemu-iotests test suite is now available


From: Kevin Wolf
Subject: Re: [Qemu-devel] the qemu-iotests test suite is now available
Date: Tue, 07 Jul 2009 09:30:47 +0200
User-agent: Thunderbird 2.0.0.21 (X11/20090320)

Christoph Hellwig schrieb:
> On Mon, Jul 06, 2009 at 01:18:04PM +0200, Kevin Wolf wrote:
>> I started to implement this, too. I'm attaching the current state of my
>> version. It's not as complete (converts only io_test() and doesn't even
>> enable different cluster sizes in the tests), but it's a pure 1:1
>> conversion and it remains compatible with the old test results which is
>> a hint that it's right at least for 4k clusters.
>>
>> I haven't reviewed your patch in much detail, but I think my patch is
>> more correct at least for the "spanning multiple L2 tables" case where
>> you still use the old hard coded numbers. With 4k clusters an L2 table
>> spans 2 MB, whereas with 64k clusters it spans 512 MB.
> 
> You're right.
> 
>> So maybe you just compare the two versions and take for each line
>> whatever looks better suited for dynamic cluster sizes.
> 
> Done.  Below is a version of my original patch with you l2 cluster size
> changes incorporate.  The problem is that I really uses up tons of disk
> space for the last test in io_test() for 64k clusters, in fact more than
> I can make available on the laptop I'm travelling with currently..

I agree, we shouldn't do it this way. 512 MB is a lot and I've heard
some people thinking about increasing the cluster size even more... So
this doesn't only take too much disk space but also a huge amount of
time for a simple test (crossing the L2 table border).

So I think what we should do is to calculate the end of the current L2
table, go back a bit and write a small amount of data, just enough to
cross the L2 border. Does that make sense?

>      # Spanning multiple L2 tables
>      # L2 table size: 512 clusters of 4k = 2M
> -    io $op $((offset + 2048)) 4194304 4999680 8
> -    offset=$((offset + 8 * 4999680))
> -
> -    if false; then
> -        true
> -    fi

offset=$(( ((offset + l2_size - 1) & ~(l2_size - 1)) - (3 * half_cluster) ))

> +    io $op $((offset + $half_cluster)) $((2 * l2_size)) 4999680 8
> +    offset=$((offset + 8 * (2 * l2_size + 512 * 1573)))
>  }

And then write 6 * half_cluster or something like that instead of 2 *
l2_size. I guess you also should change 4999680 to something like
l2_size + half_cluster, so we always hit an L2 border and test a few
different cases.

Completely untested, but I think it should work this way.

Kevin




reply via email to

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