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=0.0 required=5.0 tests=SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 Received: from len.romanrm.net (len.romanrm.net [91.121.86.59]) by gnuweeb.org (Postfix) with ESMTPS id 1F433831E1 for ; Mon, 27 Feb 2023 16:24:32 +0000 (UTC) Received: from nvm (nvm.home.romanrm.net [IPv6:fd39::101]) by len.romanrm.net (Postfix) with SMTP id 3CA7B40311; Mon, 27 Feb 2023 16:24:29 +0000 (UTC) Date: Mon, 27 Feb 2023 21:24:28 +0500 From: Roman Mamedov To: Ammar Faizi Cc: Qu Wenruo , Filipe Manana , 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 Subject: Re: [RFC PATCH v1 0/6] Introducing `wq_cpu_set` mount option for btrfs Message-ID: <20230227212428.6d852cc3@nvm> In-Reply-To: References: <20230226160259.18354-1-ammarfaizi2@gnuweeb.org> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit List-Id: On Mon, 27 Feb 2023 20:45:26 +0700 Ammar Faizi wrote: > 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. The end user should not be expected to do that. (At least that is my opinion as an end user :) The worst part, in times when Btrfs has no current work to do, it means the user apps are hard-capped to 4 cores for no good reason, and the other 4 are idling. Even with a split like 6/2, this is still looks like giving up on the achievements of multi-tasking operating systems and falling back to some antique state with fixed separation. > 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. I really hope there can be some other approach. Such as some adjustment to kworker processing so that it's not as aggressive in starving userspace. There are no possibility to run kernel task at a lower priority, right? But if no other way, maybe an option like that is good to have for the moment. -- With respect, Roman