From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 2AB29C27C53 for ; Wed, 12 Jun 2024 19:14:26 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:In-Reply-To:Content-Type: MIME-Version:References:Message-ID:Subject:Cc:To:From:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=g0Ys0OhLTEK2O9rUJZc7Ugea9cqXuSY8noCvfRM0Osw=; b=HLrMuIahj10dX375gblkfgX7Sk y0BIO0O9LHwqo2aCqOPD8Y2WxlAegZRlDwJsz+pl6hlMwelOUzyzvHTvT0fzk8Db2tGWlaS0lufrI tPMfJPC56S3T38fg/OFRKBd5gQTq7dEVDk7vryXG5Bq8Kb37qP0A3Rh8bF5iRCrmB3HqW55klNmx8 5odesTyGOA1CHveHLraSULZPr0JPB6a1+jjnpCrFHGdR+rqjJgXGaa8iF09TRcxYLMMG7QWWzEESl BtKjoDD6HUcMHIn5XLLjFoOsrQE1EHoshtYd3EfID7q+GxECicaQUtbxazCrIa+ICqBNpWvulOqMF CYi+86SA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1sHTQC-0000000DrhE-3jF8; Wed, 12 Jun 2024 19:14:12 +0000 Received: from dfw.source.kernel.org ([2604:1380:4641:c500::1]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1sHTQA-0000000Drgd-2ppo for linux-arm-kernel@lists.infradead.org; Wed, 12 Jun 2024 19:14:12 +0000 Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id 1C95A60AAD; Wed, 12 Jun 2024 19:14:10 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 0F755C116B1; Wed, 12 Jun 2024 19:14:08 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1718219649; bh=IkuOVIKmhBNyEVZ4pzMiaylc6sEfQehwLzgJTI2arLs=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=dtZNNTr+zNrJyarcL+xMd9BfhFyLD6clDZTqSk7LwK4EDDaj9vtguy/f09nb6GyyY DxN+1JJZWbOSRznIZQcXdrOIexDW0G/ICuzxiQlP46gldk5PHB2inCvIHWy9iiOjZh KeCK86mVoIamVNpiIihT8MMeOXKdTi4og6onRXD9rgmmTlNxMEpPbjTs+Tdq2VqMI7 QMgAITS7kkwvnjotYrJs2gqTTFDgQrdWYTlSAQzCoAcUo4xZb7waFp9/OmmDzOXQ/Q Frj3a2Pr3o5RCx+01mDNb4X+ldK66OdQ1NK3168ACiqHmoDQmkqpDwAe0FRDYWL8R9 Tzrmv2j2I+HhA== Date: Wed, 12 Jun 2024 12:14:06 -0700 From: Eric Biggers To: Herbert Xu Cc: linux-crypto@vger.kernel.org, fsverity@lists.linux.dev, dm-devel@lists.linux.dev, x86@kernel.org, linux-arm-kernel@lists.infradead.org, Ard Biesheuvel , Sami Tolvanen , Bart Van Assche Subject: Re: [PATCH v5 15/15] dm-verity: improve performance by using multibuffer hashing Message-ID: <20240612191406.GA1298@quark.localdomain> References: <20240611034822.36603-1-ebiggers@kernel.org> <20240611034822.36603-16-ebiggers@kernel.org> <20240612153829.GC1170@sol.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20240612153829.GC1170@sol.localdomain> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240612_121410_794983_00D92720 X-CRM114-Status: GOOD ( 23.89 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Wed, Jun 12, 2024 at 08:38:29AM -0700, Eric Biggers wrote: > On Wed, Jun 12, 2024 at 05:31:17PM +0800, Herbert Xu wrote: > > On Mon, Jun 10, 2024 at 08:48:22PM -0700, Eric Biggers wrote: > > > > > > + if (++io->num_pending == v->mb_max_msgs) { > > > + r = verity_verify_pending_blocks(v, io, bio); > > > + if (unlikely(r)) > > > + goto error; > > > } > > > > What is the overhead if you just let it accumulate as large a > > request as possible? We should let the underlying algorithm decide > > how to divide this up in the most optimal fashion. > > > > The queue adds 144*num_messages bytes to each bio. It's desirable to keep this > memory overhead down. So it makes sense to limit the queue length to the > multibuffer hashing interleaving factor. Yes we could build something where you > could get a marginal performance benefit from amounts higher than that by saving > indirect calls, but I think it wouldn't be worth bloating the per-IO memory. > > Another thing to keep in mind is that with how the dm-verity code is currently > structured, for each data block it gets the wanted hash from the Merkle tree > (which it prefetched earlier) before hashing the data block. So I also worry > that if we wait too long before starting to hash the data blocks, dm-verity will > spend more time unnecessarily blocked on waiting for Merkle tree I/O. To clarify, 144*num_messages bytes is for the current version that doesn't have a redundant shash_desc (or ahash_request which is even bigger) for each block. If you force those to be included, then that would of course go up. Also, we can't really swap the order of "hashing a data block" and "getting the wanted hash of the block" in order to avoid the second issue I mentioned, because that would require removing the optimization where dm-verity zero-fills blocks whose hashes are the hash of the zero block instead of verifying them. So it seems like the downsides of queueing up too many blocks outweigh the potential benefits. - Eric