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=DKIM_SIGNED,DKIM_VALID, RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE, SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 Received: from mail-pj1-f42.google.com (mail-pj1-f42.google.com [209.85.216.42]) by gnuweeb.org (Postfix) with ESMTPS id DF209831B7 for ; Mon, 27 Feb 2023 22:17:49 +0000 (UTC) Authentication-Results: gnuweeb.org; dkim=pass (2048-bit key; unprotected) header.d=fromorbit-com.20210112.gappssmtp.com header.i=@fromorbit-com.20210112.gappssmtp.com header.a=rsa-sha256 header.s=20210112 header.b=c3RRuHU2; dkim-atps=neutral Received: by mail-pj1-f42.google.com with SMTP id x20-20020a17090a8a9400b00233ba727724so210375pjn.1 for ; Mon, 27 Feb 2023 14:17:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fromorbit-com.20210112.gappssmtp.com; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=mPM2MT4l22bSLqZbp1zzdMjwuCto4MQv4gVU0GLg09o=; b=c3RRuHU2onk5Ll4yH0rWp94BqSk4DSJw35QyBkGUaFa0WGN4tgO2TcNVzhoYIx+7PH DVLzen85rSVguCwv9NApLo93L2laz9K6tOeBUBJvz486/ZLlTL5qVvC6kpnmwOCm9Pjr LVfvQcT4dxC4qxQBqbsYuUqwvU50L5wJerBgWIDGMGeV+E1BQas6rvjFc65e3rs3IA2q 9KlezrP7s25qLNC2O8rGQ2Rf2lu7RDsHCfqiwB1XmqR6ubPxGCE+79xQ8nWxaEf4u+wc m298ViMCUknvpjJh5377alzfmmeSpITHNi140aNl0erKfh0vAWKeHCIOR2TY7vPLFA8N 4R3A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=mPM2MT4l22bSLqZbp1zzdMjwuCto4MQv4gVU0GLg09o=; b=qBUftbZS3lNDG4yIdbUPaFUUyZlyilCeGToGwQFV65h5oEfkD70+xbqluH62BejZid +u5poGI7rnR/EXdPuHiEbNxMlFHNKIO3NyQ3jk4eQW0OlQkgI8hi3qrI81P7ZT7ocEZR biJg0gFxAy32Eom1ATwTp+vxjsPm+FEjncEprkpBCR8BMDLDmNmyv7EMlHEmkXaTP51W mX7SS9AENGCYnafdrRSlHmTavkT0EqwiFGh/eJAvVwbaeoFpbkQa6IK5QVO01sLwWT7p 5Dj8ePayll/Ffws+U+PLUQJIesyAWNu6OorYt6YbY7UzA6ZndlW83hjh93CDU0aU1PG5 DITw== X-Gm-Message-State: AO0yUKUlsB0pQILlXQtR9UTzVoT2vBklAkp4pfu5IDNZEWMo5chXeDJm vMQZmo4Qm/XAUt+BDsfMudcKdQ== X-Google-Smtp-Source: AK7set/UWLuA22t/X7nw5ppBZa0/KoERUzGb05/5qRp1Ftv4fGoo0pk3i5p98gZJeVqpUqkw9mF5YQ== X-Received: by 2002:a17:903:22cf:b0:19d:1686:989 with SMTP id y15-20020a17090322cf00b0019d16860989mr490126plg.59.1677536269102; Mon, 27 Feb 2023 14:17:49 -0800 (PST) Received: from dread.disaster.area (pa49-186-4-237.pa.vic.optusnet.com.au. [49.186.4.237]) by smtp.gmail.com with ESMTPSA id u13-20020a170902714d00b00198e7d97171sm5059718plm.128.2023.02.27.14.17.48 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 27 Feb 2023 14:17:48 -0800 (PST) Received: from dave by dread.disaster.area with local (Exim 4.92.3) (envelope-from ) id 1pWloX-002tUp-Ps; Tue, 28 Feb 2023 09:17:45 +1100 Date: Tue, 28 Feb 2023 09:17:45 +1100 From: Dave Chinner To: Ammar Faizi 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 Subject: Re: [RFC PATCH v1 0/6] Introducing `wq_cpu_set` mount option for btrfs Message-ID: <20230227221745.GI2825702@dread.disaster.area> References: <20230226160259.18354-1-ammarfaizi2@gnuweeb.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20230226160259.18354-1-ammarfaizi2@gnuweeb.org> List-Id: On Sun, Feb 26, 2023 at 11:02:53PM +0700, Ammar Faizi wrote: > ## Test wq_cpu_set > sudo mount -t btrfs -o rw,compress-force=zstd:15,commit=1500,wq_cpu_set=0.4.1.5 /dev/sda2 hdd/a; > cp -rf /path/folder_with_many_large_files/ hdd/a/test; > sync; # See the CPU usage in htop. > sudo umount hdd/a; This seems like the wrong model for setting cpu locality for internal filesystem threads. Users are used to controlling cpu sets and other locality behaviour of a task with wrapper tools like numactl. Wrap th emount command with a numactl command to limit the CPU set, then have the btrfs fill_super() callback set the cpu mask for the work queues it creates based on the cpu mask that has been set for the mount task. That is, I think the model should be "inherit cpu mask from parent task" rather than adding mount options. This model allows anything that numactl can control (e.g. memory locality) to also influence the filesystem default behaviour without having to add yet more mount options in the future.... -Dave. -- Dave Chinner david@fromorbit.com