From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mta1.migadu.com (out-238.mta1.migadu.com [95.215.58.238]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 20EE34F30E6 for ; Tue, 8 Sep 2026 15:37:24 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=95.215.58.238 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1788881850; cv=none; b=pCYeOjunCZwSDQNJdghpRYde7CNEZt4bAELaUrsGpKRDnRH5H4jrvvTriTzFd5/spNpBbSpzswlSdyrjPo9+yHNVg32McfX8c3zXEz3CeZAC/kBicPoA+if4dQPQNW+7Ecm3j4Sptt3kk1uhZtUZxVG+YWt1wK7+gYF8bD6mgMk= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1788881850; c=relaxed/simple; bh=3F5irEjcISX4qX8MMi5ghXCJUDGX2AOsa87ikrXlkOM=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=h/1Ln99j5AAhYU1d/0ouR9pkxdfS5KIda7V7XerIc4sc/o7llkeGPlbT4sBZblE4u9vUUyCKkGjDhM3OvrdqKoup/3OaFrQogaBch33O2YDW3pxoa9F8GXNgEoVS1+TseTkbvffCwjIKQuclhrxFJiF3Wak7OuvEoX2OzumOnOk= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev; spf=pass smtp.mailfrom=linux.dev; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b=eZ3PFfqJ; arc=none smtp.client-ip=95.215.58.238 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.dev Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b="eZ3PFfqJ" X-Envelope-To: linux-kernel@vger.kernel.org DKIM-Signature: a=rsa-sha256; bh=3F5irEjcISX4qX8MMi5ghXCJUDGX2AOsa87ikrXlkOM=; c=simple/simple; d=linux.dev; h=from:to:subject:date:message-id:mime-version:content-type; s=key1; t=1788881840; v=1; x=1789486640; b=eZ3PFfqJvqeo/i9kY0Ajclq8VcPADd0tdr1qJzPiXNDVHEtOC13S+IwRP8vqdKI9RnHayKi6 IbvTaU0doRb9sqeCgL63goIAtedqm5qrQ0407IbrxU3pkO3po87RyA1Lkrk6DjULfUn/qaaqaSZ xgTYFHShOCDQkNEU6ZmWmolk= X-Envelope-To: linux-kernel@vger.kernel.org Received: by mta10.migadu.com with ESMTPS id 5be14b208c221cb5; Tue, 08 Sep 2026 15:37:20 +0000 X-Mizu-Trace-ID: 5be14b208c221cb5 X-Migadu-Flow: FLOW_OUT From: Usama Arif To: Usama Arif Cc: davem@davemloft.net, dsterba@suse.com, Herbert Xu , linux-crypto@vger.kernel.org, linux-kernel@vger.kernel.org, terrelln@fb.com, terrelln@meta.com, cyan@meta.com, hannes@cmpxchg.org, yosry@kernel.org, nphamcs@gmail.com, chengming.zhou@linux.dev, shakeel.butt@linux.dev, kernel-team@meta.com Subject: Re: [PATCH 0/2] crypto: zstd - avoid initializing the workspace twice Date: Tue, 8 Sep 2026 08:37:13 -0700 Message-ID: <20260908153715.3063790-1-usama.arif@linux.dev> X-Mailer: git-send-email 2.53.0 In-Reply-To: <20260825220616.3842633-1-usama.arif@linux.dev> References: Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit On Tue, 25 Aug 2026 15:06:00 -0700 Usama Arif wrote: > Both zstd_compress() and zstd_decompress() set up the shared per-CPU > workspace as a C/DStream before walking the request, and then, when the > first source and destination fragments each span the whole request, hand > off to zstd_compress_one()/zstd_decompress_one(), which immediately > overwrite that same ctx->wksp with a CCtx/DCtx. The stream setup is > discarded without a byte having been processed. > > That one-shot path is not a corner case: zswap always takes it when > storing, and takes it for a load whenever the stored object lies within a > single zsmalloc page. > > These two patches defer the stream initialization to the first walk > iteration that actually streams, guarded by a flag because that iteration > can be reached more than once. > > A 4 KiB crypto_acomp benchmark [1], twelve runs of nine 30,000-operation > rounds. Bare metal is an Intel Xeon Platinum 8321HC, turbo off, > performance governor, pinned to one core; the VM is a one-vCPU KVM guest > on a faster host. > > baseline patched delta > bare metal > compress 52,283 ns 51,038 ns 1,245 ns 2.4% > decompress 2,317 ns 1,998 ns 319 ns 13.8% > one-vCPU KVM > compress 16,675 ns 15,050 ns 1,625 ns 9.8% > decompress 3,516 ns 2,265 ns 1,251 ns 35.6% > > The guest numbers are larger because the two CPUID instructions in > ZSTD_cpuid() become unconditional VM exits there. > > [1] https://gist.github.com/uarif1/5cf02f0e22c23f0d1b3d84348f12914c Hi, Just wanted to check if there was any feedback or review of the series. I think its a nice optimization and even with the CPUID instructions getting cached [1], this is still needed. The improvement in baremetal is not coming (just) from CPUID instructions. [1] https://lore.kernel.org/all/20260901110850.1805747-1-usama.arif@linux.dev/ Thanks, Usama