xfs
[Top] [All Lists]

Re: [patch] xfsqa 008 takes too long on UML...

To: David Chinner <dgc@xxxxxxx>
Subject: Re: [patch] xfsqa 008 takes too long on UML...
From: Timothy Shimmin <tes@xxxxxxx>
Date: Tue, 13 May 2008 16:24:11 +1000
Cc: xfs-dev <xfs-dev@xxxxxxx>, xfs-oss <xfs@xxxxxxxxxxx>
In-reply-to: <20080512110134.GH155679365@xxxxxxx>
References: <20080512110134.GH155679365@xxxxxxx>
Sender: xfs-bounce@xxxxxxxxxxx
User-agent: Thunderbird 2.0.0.14 (Macintosh/20080421)
Sounds reasonable to me.
Might be nice to have the description as a comment in the test
so it is easy to see the thought behind the calculations
in the future.

--Tim

David Chinner wrote:
> With the recent change for reliability with 64k page size
> made to test 008,the file sizes got much larger. It appears
> that randholes actually reads the entire file, so this has
> slowed the test down by a factor of ten (all file sizes
> were increased by 10x). This means the test is now taking
> about 18 minutes to run on a UML session, and all the time
> is spent reading the files.
> 
> Instead, scale the file size based on the page size. We know
> how many holes we are trying to produce and the I/O size
> being used to produce them, so the size of the files can be
> finely tuned. Assuming a decent random distribution, if the
> number of blocks in the file is 4x the page size and the
> I/O size is page sized, this means that every I/O should
> generate a new hole and we'll only get a small amount of
> adjacent extents. This has passed over 10 times on ia64
> w/ 64k page and another 15 times on UML with 4k page.
> 
> UML runtime is down from ~1000s to 5s, ia64 runtime is down from
> ~30s to 7s.
> 
> Cheers,
> 
> Dave.


<Prev in Thread] Current Thread [Next in Thread>