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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id D1296EB64DA for ; Wed, 19 Jul 2023 06:35:00 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230490AbjGSGe7 convert rfc822-to-8bit (ORCPT ); Wed, 19 Jul 2023 02:34:59 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57520 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230055AbjGSGe6 (ORCPT ); Wed, 19 Jul 2023 02:34:58 -0400 Received: from mail.lichtvoll.de (lichtvoll.de [IPv6:2001:67c:14c:12f::11:100]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 5C26B1FCE for ; Tue, 18 Jul 2023 23:34:54 -0700 (PDT) Received: from 127.0.0.1 (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (secp384r1) server-digest SHA384) (No client certificate requested) by mail.lichtvoll.de (Postfix) with ESMTPSA id 9F7887478A6; Wed, 19 Jul 2023 08:34:51 +0200 (CEST) Authentication-Results: mail.lichtvoll.de; auth=pass smtp.auth=martin smtp.mailfrom=martin@lichtvoll.de From: Martin Steigerwald To: linux-btrfs@vger.kernel.org, Qu Wenruo Subject: Re: [PATCH RFC 0/4] btrfs: scrub: make sctx->stripes[] a ring buffer Date: Wed, 19 Jul 2023 08:34:51 +0200 Message-ID: <2250219.iZASKD2KPV@lichtvoll.de> In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 8BIT Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-btrfs@vger.kernel.org Hi Qu. Qu Wenruo - 19.07.23, 07:30:22 CEST: > This is the attempt to increase the queue depth of the scrub behavior. > > Although it has a slight increase on the queue depth, it's not enough > to cause any obvious performance increase. > > It's still short of 2GiB/s. […] > Thus this patch is mostly sent asking for better ideas. Hmm, another approach would be to revert the patches that introduced the performance regression. It would release the pressure to find a fix soon. Then you'd have all the time to have another go at improving scrubbing. At least the issue at hand seems to be tricky. What you think? Thanks, -- Martin