On 19.01.2017 15:18, Alberto Garcia wrote: > On Wed 18 Jan 2017 04:30:49 PM CET, Max Reitz wrote: > >>> In other words: the vast majority of the entries in the refcount >>> table are probably not going to be used ever, but we're still >>> checking them for each write request. One user reported a >200% >>> performance increase on a fast SSD when using overlap-check=constant. >>> >>> I think this is at least worth documenting a bit better (unless >>> there's existing documentation that I have missed), but my main >>> question is: does it make sense to try to optimize these checks, or >>> is it better to simply tell the user to disable them in these >>> scenarios? >> >> I have optimized these checks. See: >> >> http://lists.nongnu.org/archive/html/qemu-block/2015-08/msg00020.html >> >> Feel free to review. If you want, I can rebase the series. >> >> So far nobody has seriously done so because it wasn't considered >> important enough, and the patches are not exactly trivial. > > I see. I wonder if it's worth complicating the code so much more instead > of simply disabling the tests. > > For the 'refcount-block' check, which is the one that has an immediate > impact in all kinds of images, I was wondering if we could simply use > the image size to determine how many entries need to be checked. This > would keep things much faster unless the image grows abnormally bigger.
Have you tested that it helps? I would assume that checking one (mostly) unused cluster of the refcount table does not take longer than checking a single refcount block. Any entry that's 0 will just be skipped. Max
signature.asc
Description: OpenPGP digital signature
