Hi On Wed, 22 Jan 2025, Harald Freudenberger wrote: > > 6.13.0-rc7 with dm-integrity using shash: > > sha256 > WRITE: 4294967296 bytes (4.3 GB, 4.0 GiB) copied, 45.5 s, 94.4 MB/s > READ: 4294967296 bytes (4.3 GB, 4.0 GiB) copied, 19.2137 s, 224 MB/s > hmac-sha256 > WRITE: 4294967296 bytes (4.3 GB, 4.0 GiB) copied, 45.2026 s, 95.0 MB/s > READ: 4294967296 bytes (4.3 GB, 4.0 GiB) copied, 19.2082 s, 224 MB/s > > 6.13.0-rc7 with dm-integrity with my ahash patch: > > sha256 > WRITE: 4294967296 bytes (4.3 GB, 4.0 GiB) copied, 41.5273 s, 103 MB/s > READ: 4294967296 bytes (4.3 GB, 4.0 GiB) copied, 16.2558 s, 264 MB/s > hmac-sha256 > WRITE: 4294967296 bytes (4.3 GB, 4.0 GiB) copied, 44.063 s, 97.5 MB/s > READ: 4294967296 bytes (4.3 GB, 4.0 GiB) copied, 16.5381 s, 260 MB/s > > I checked these results several times. They vary but always the dm-integrity > with the ahash patch gives the better figures. I ran some measurements with > an isolated cpu and used this cpu to pin the format or the dd task to this > cpu. Pinning is not a good idea as very much of the work is done via > workqueues > in dm-integrity and so the communication overhead between the cpus increases. > However, I would have expected a slight penalty with the ahash patch like > it is to see with the dm-integrity format but read and write seem to benefit > from this simple ahash patch. It would be very interesting how a real asynch > implementation of dm-integrity really performs. > > If someone is interested, I can share my scripts for these measurements. > > Harald Freudenberger If ahash helps for you, you can add it in a similar way to the dm-verity target - so that it is only used when it makes sense - see the function verity_setup_hash_alg. Mikulas
