From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on gnuweeb.org X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM, NICE_REPLY_A,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.6 Received: from mail-pj1-f53.google.com (mail-pj1-f53.google.com [209.85.216.53]) by gnuweeb.org (Postfix) with ESMTPS id CFED9831E1 for ; Mon, 27 Feb 2023 13:45:57 +0000 (UTC) Authentication-Results: gnuweeb.org; dkim=pass (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256 header.s=20210112 header.b=ZzJXXHoZ; dkim-atps=neutral Received: by mail-pj1-f53.google.com with SMTP id kb15so6168775pjb.1 for ; Mon, 27 Feb 2023 05:45:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:in-reply-to:subject:from:content-language :references:cc:to:user-agent:mime-version:date:message-id:from:to:cc :subject:date:message-id:reply-to; bh=CzmZnimNpH+EYXZ0bDiVoPJjPd0s6EF9C+qx53bSQDI=; b=ZzJXXHoZM/CzyJMIT0Vd2FuqJwOWi3ZiAyVSIdc7G6v6HGERSoQrbFl3CmkMbEOnLe FbpGGrrQEHUm9Rgq6jx/+TXe15M3qf3w3Vh4q6anEQ4uAvoQfYbEt+DvWNW1KY4OIJ3p RBFv/zRS5jMOxUzJl2gA7gGnparcii/lfOL8ZMCau+/oUyGlMPHuyUHZGx44ZG86yclk tooJpJQoGp6m/BY4hx0fFafeoQ1I7ieHk1WvE45EAUPsIBlwtKLeJ9HRf3x4fsD8kwYT WQD3rUGs8DYYOgry/K/zvLtfBElIZKBk2AZOwe40hugW1vgw+5LzjXEF0OePfsWGm+MZ flgg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:subject:from:content-language :references:cc:to:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=CzmZnimNpH+EYXZ0bDiVoPJjPd0s6EF9C+qx53bSQDI=; b=BDstNGKx2cxUoSaPpq82wXTdpSG4r+cm9P5j43H6OMFv06HnAcLsDIT5LFvRyxUZIG DFtdOYT4hvGH69ES3F0OU7xIWnlzWa0SDVzYT3S30zD8koYnX9NaJpuQXGhC+Mp0A0n6 k2sLbO0K6Z5fjvMLEfTSxmAAhCzWt8WLOO83WMNaiEQQ9r6rxP/+XPQTCtvSXDYmt5hH iHDGC6SI0W53tFCtUWU99NGNKB36z9/jJr/nnl5rhU9M+7SkfIQcDse9/XCttyhzp0Nm OY7Wpg09OvVkgLihzN3MMkDdJ73T38P1wLWUnEZJzS5gNmbDRFyzODoHXRv4ErmErO0O jH7A== X-Gm-Message-State: AO0yUKVNkAQcStux3A7dUCXOt2L/ZA9DVKwiIrMcS2rI9vyFutMw9EGZ HHMj9sFzE0IMasyvmn7mUDI= X-Google-Smtp-Source: AK7set90PO9ecxcI2ys6lRPTe63kfXEIBrwfCYOYDLP+DSyx0qzIGI1tHu3XlHcF06v42vC1zlg7qQ== X-Received: by 2002:a05:6a20:9383:b0:cb:af96:9436 with SMTP id x3-20020a056a20938300b000cbaf969436mr21854292pzh.0.1677505557052; Mon, 27 Feb 2023 05:45:57 -0800 (PST) Received: from [192.168.136.80] ([182.2.39.140]) by smtp.gmail.com with ESMTPSA id u24-20020a62ed18000000b005d663989ccfsm4241295pfh.200.2023.02.27.05.45.48 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 27 Feb 2023 05:45:56 -0800 (PST) Message-ID: Date: Mon, 27 Feb 2023 20:45:26 +0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.7.1 To: Qu Wenruo , Filipe Manana Cc: Chris Mason , Josef Bacik , David Sterba , Tejun Heo , Lai Jiangshan , Filipe Manana , Linux Btrfs Mailing List , Linux Kernel Mailing List , Linux Fsdevel Mailing List , GNU/Weeb Mailing List References: <20230226160259.18354-1-ammarfaizi2@gnuweeb.org> Content-Language: en-US From: Ammar Faizi Subject: Re: [RFC PATCH v1 0/6] Introducing `wq_cpu_set` mount option for btrfs In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit List-Id: On 2/27/23 6:46 PM, Qu Wenruo wrote: > On 2023/2/27 19:02, Filipe Manana wrote: >> On Sun, Feb 26, 2023 at 4:31 PM Ammar Faizi wrote: >>> Figure (the CPU usage when `wq_cpu_set` is used VS when it is not): >>> https://gist.githubusercontent.com/ammarfaizi2/a10f8073e58d1712c1ed49af83ae4ad1/raw/a4f7cbc4eb163db792a669d570ff542495e8c704/wq_cpu_set.png >> >> I haven't read the patchset. >> >> It's great that it reduces CPU usage. But does it also provide >> other performance benefits, like lower latency or higher throughput >> for some workloads? Or using less CPU also affects negatively in >> those other aspects? Based on my testing, it gives lower latency for a browser app playing a YouTube video. Without this proposed option, high-level compression on a btrfs storage is a real noise to user space apps. It periodically freezes the UI for 2 to 3 seconds and causes audio lag; it mostly happens when it starts writing the dirty write to the disk. It's reasonably easy to reproduce by making a large dirty write and invoking a "sync" command. Side note: Pin user apps to CPUs a,b,c,d and btrfs workquques to CPUs w,x,y,z. > So far it looks like to just set CPU masks for each workqueue. > > Thus if it's reducing CPU usage, it also takes longer time to finish > the workload (compression,csum calculation etc). Yes, that's correct. I see this as a good mount option for btrfs because the btrfs-workload in question is CPU bound, specifically for the writing operation. While it may degrade the btrfs workload because we limit the number of usable CPUs, there is a condition where users don't prioritize writing to disk. Let's say: I want to run a smooth app with video. I also want to have high-level compression for my btrfs storage. But I don't want the compression and checksum work to bother my video; here, I give you CPU x,y,z for the btrfs work. And here I give you CPU a,b,c,d,e,f for the video work. I have a similar case on a torrent seeder server where high-level compression is expected. And I believe there are more cases where this option is advantageous. Thank you all for the comments, -- Ammar Faizi