Received: by 10.192.165.148 with SMTP id m20csp806602imm; Fri, 20 Apr 2018 16:34:41 -0700 (PDT) X-Google-Smtp-Source: AIpwx49qJ1BwUACstfUmwCmDnkNWbTzVGq8WWfBS1WpoUdHzrde8/UoZQkvPES9WpCUbs5ko4vlj X-Received: by 2002:a17:902:9a0b:: with SMTP id v11-v6mr12035415plp.387.1524267281501; Fri, 20 Apr 2018 16:34:41 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1524267281; cv=none; d=google.com; s=arc-20160816; b=hDie44kIZTzzjneRfzrn9edja+w8g5RK45pfVLkJ+tVqaODik2C04FeK6RNh31tSzh tL7DM+W4KMf6jDZ5fGUA7fe3gYdw8Kvvs2H60pDUEAY1oHm+nT2hKfjpXJ1tia4NqVke SQGNBQOricYNvXaT02zHvpZ98V9ynlGUAZ8eJDQRbGfnt+6kp2duWKA7me6t0qnI0m6P zk0BtF5gbguy1MCEkKEQ1nNwab2IKtxP5cfRFHQ6Bo4/3a1NNokNFfEzTYtfZR7C7INS ObPeQ4uCcRn4hEkQ/+QKdhqe7LeXOSL+SZjKfs1mAJ68zYHr6J7SfG/xx2QZKRJwCXwO DxkA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:message-id:date:subject:cc:to:from :dkim-signature:arc-authentication-results; bh=6AX/EpRpO7UGlHKwOCGYenGa20cKGfyyyvaH7fEGlgQ=; b=C0eD9hGsIanOw8v/BaW/6V1ehznYTACTQ0cP8AT/iVFH+JxiP7brQ6qEda2ZRJ7p96 QmJWfaow5nNyYt4XtsaX8H0/MCai7C+m076Ipg/wDj/pwEy6j/Xj1qDamkQjiVfE1xPp NTCHRfvQ5Gblx/t7kzE/nosiIvpHZIbDjT4pgLBJEgrix7YIWg2KVwEog1nQkIOojvgC W0nDVOLmtqOlQ4JtZub1oh4adeZpT8Or7sBNjhnfZbgKEB6ABhf1QTLpfVh2180rwqgm 2DOwPY8S0a/uo1gDfO6NxeK5NzOqKrfCimvq+1dnNtGkPzWDARR3Okmscg7Kaq6khlNQ 0mzw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=eO5vvzMr; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id s15-v6si6477455plp.243.2018.04.20.16.34.03; Fri, 20 Apr 2018 16:34:41 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=eO5vvzMr; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752700AbeDTXbX (ORCPT + 99 others); Fri, 20 Apr 2018 19:31:23 -0400 Received: from mail-pl0-f48.google.com ([209.85.160.48]:37293 "EHLO mail-pl0-f48.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751325AbeDTXbV (ORCPT ); Fri, 20 Apr 2018 19:31:21 -0400 Received: by mail-pl0-f48.google.com with SMTP id f7-v6so6039432plr.4 for ; Fri, 20 Apr 2018 16:31:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=from:to:cc:subject:date:message-id; bh=6AX/EpRpO7UGlHKwOCGYenGa20cKGfyyyvaH7fEGlgQ=; b=eO5vvzMrp3UQG9mFyrMVfrERE40mzWy+V7otp45AqnE6ssjOJ57VGXAhbMDE6Avwry EwNGDV77fdBN72uVHId4ZwCgzwic3RRVkS8VO5wiHvZbm9e30D7cAaGyvUptV0pP+8Vu PuTDKI4iOWuwKYvOS+Acwd9jpqBF28NufRCrp21u0/YYWH9E5241d8cUMkpzlxagxBJv hOUa63n4m3vEyD/mDK/sM+4wEiqDKRTqWDzI4L+jx5fuLk5mLva0lJzgH/Ea/0rAulyY sRkRFki6NqBnh4ZAgdoffhvjH4C2olUlNfYxvTMWXr7blJzQIBVwsscmoX0SwyjbPLpu U9iw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id; bh=6AX/EpRpO7UGlHKwOCGYenGa20cKGfyyyvaH7fEGlgQ=; b=aYxmV9SW1QmGhHeKMNLbepwbSbjy07HJWfj6y7WSdsp3FOAfGd+++EA/IAt7Gksk/S S5KNPRlIWKTnWcTdxckQwXID3QUiNL0UVPXb8rIbNo607+WAO3p3sCbvsH+fMMHMEwOG bfrft+ifPCGXdsINerB60TU0eFm6KlGyApujd//BvUA6dCdpk18cSlxCZsiItoJus69b LQQ7LEJOHcxFgZrOUqXuIadfR5SAjsRKSp4IJDY3n0KcQ+VgrfmyB7kn5VVRptbPYM91 FrEKjhKMfkLxXmnX/Qy24LHFYs0cU2flFMFYap3w7u0DmToyhWpCyZHWV7u3VB4tHXW/ bM4Q== X-Gm-Message-State: ALQs6tDCdoHpNhaRyd7wDWd5yUkw1xsoEdJtVpsb7qo18Z2ufOvPticy JymlVU8Y6D90aFMcgo+CS/JVMQ== X-Received: by 2002:a17:902:265:: with SMTP id 92-v6mr11560653plc.368.1524267080775; Fri, 20 Apr 2018 16:31:20 -0700 (PDT) Received: from ebiggers-linuxstation.kir.corp.google.com ([2620:15c:17:3:dc28:5c82:b905:e8a8]) by smtp.gmail.com with ESMTPSA id p6sm14235885pfk.104.2018.04.20.16.31.18 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 20 Apr 2018 16:31:19 -0700 (PDT) From: Eric Biggers To: linux-fscrypt@vger.kernel.org, "Theodore Y . Ts'o" Cc: Jaegeuk Kim , Paul Crowley , Enric Balletbo i Serra , Mikulas Patocka , linux-kernel@vger.kernel.org, Eric Biggers Subject: [PATCH] fscrypt: use unbound workqueue for decryption Date: Fri, 20 Apr 2018 16:30:02 -0700 Message-Id: <20180420233002.134687-1-ebiggers@google.com> X-Mailer: git-send-email 2.17.0.484.g0c8726318c-goog Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Improve fscrypt read performance by switching the decryption workqueue from bound to unbound. With the bound workqueue, when multiple bios completed on the same CPU, they were decrypted on that same CPU. But with the unbound queue, they are now decrypted in parallel on any CPU. Although fscrypt read performance can be tough to measure due to the many sources of variation, this change is most beneficial when decryption is slow, e.g. on CPUs without AES instructions. For example, I timed tarring up encrypted directories on f2fs. On x86 with AES-NI instructions disabled, the unbound workqueue improved performance by about 25-35%, using 1 to NUM_CPUs jobs with 4 or 8 CPUs available. But with AES-NI enabled, performance was unchanged to within ~2%. I also did the same test on a quad-core ARM CPU using xts-speck128-neon encryption. There performance was usually about 10% better with the unbound workqueue, bringing it closer to the unencrypted speed. The unbound workqueue may be worse in some cases due to worse locality, but I think it's still the better default. dm-crypt uses an unbound workqueue by default too, so this change makes fscrypt match. Signed-off-by: Eric Biggers --- fs/crypto/crypto.c | 11 ++++++++++- 1 file changed, 10 insertions(+), 1 deletion(-) diff --git a/fs/crypto/crypto.c b/fs/crypto/crypto.c index ce654526c0fb..984e190f9b89 100644 --- a/fs/crypto/crypto.c +++ b/fs/crypto/crypto.c @@ -427,8 +427,17 @@ int fscrypt_initialize(unsigned int cop_flags) */ static int __init fscrypt_init(void) { + /* + * Use an unbound workqueue to allow bios to be decrypted in parallel + * even when they happen to complete on the same CPU. This sacrifices + * locality, but it's worthwhile since decryption is CPU-intensive. + * + * Also use a high-priority workqueue to prioritize decryption work, + * which blocks reads from completing, over regular application tasks. + */ fscrypt_read_workqueue = alloc_workqueue("fscrypt_read_queue", - WQ_HIGHPRI, 0); + WQ_UNBOUND | WQ_HIGHPRI, + num_online_cpus()); if (!fscrypt_read_workqueue) goto fail; -- 2.17.0.484.g0c8726318c-goog