Re: [PATCH v14 05/21] fsverity: improve flushing performance of fsverity_fill_zerohash
Eric Biggers via Linux-f2fs-devel <[email protected]> Tue, 4 Aug 2026 18:37:52 +0000
| Newsgroups | gmane.linux.file-systems.f2fs,gmane.linux.file-systems,gmane.comp.file-systems.ext4,gmane.comp.file-systems.btrfs |
|---|---|
| Message-ID | <[email protected]> |
On Tue, Aug 04, 2026 at 07:42:23PM +0200, Christoph Hellwig wrote: > On Mon, Aug 03, 2026 at 10:07:55PM +0200, Andrey Albershteyn wrote: > > The current version calls flush_dcache_folio(), in memcpy_to_folio(), to > > flush whole folio on every digest (which is 128 for 4k) on the HIGHMEM > > systems. Open code folio mapping and flushing to copy all digests at > > once. > > This looks correct, although to me optimizing for this feels like > premature optimizations not worth the ugly code unless we have numbers > to justify it. > > If Eric wants it: > > Reviewed-by: Christoph Hellwig <[email protected]> > > > + if (folio_test_partial_kmap(folio) && > > + off > PAGE_SIZE - offset_in_page(offset)) > > + off = PAGE_SIZE - offset_in_page(offset); > > + for (; to < (vaddr + off); to += vi->tree_params.digest_size) > > Style nitpick: no need for braces when comparing with simple > integer arithmetics like this. > > > + for (off = offset; off < (offset + len); > > Same here. Well I didn't ask for it per se, but I pointed it out and asked whether anyone will care about the combination of XFS && FS_VERITY && HIGHMEM. Based on Darrick's email it seems the answer may be no? If it's kept as-is, adding a comment mentioning that it doesn't need to be optimized for HIGHMEM would help preempt any questions about it. - Eric