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 6EB44C4167B for ; Fri, 8 Dec 2023 15:40:04 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1574378AbjLHPj4 (ORCPT ); Fri, 8 Dec 2023 10:39:56 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:32960 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1574350AbjLHPjx (ORCPT ); Fri, 8 Dec 2023 10:39:53 -0500 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 739AEFB for ; Fri, 8 Dec 2023 07:40:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1702049999; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=QVNp5yABNZJprMXFRXBef0K1nSQmZiO4SNxd+eql7bc=; b=cloKEpw5QIymDPebOPsP7ekNk4uvEATv/K4y8B9Kq2RwRzoneqVI6TPx4KRoy4fbrE1jcb EDsp7k9EfGTFvilInkz7KeTRF7WAKPN5vkly8R9HiVezhvKH5YGXIs5kx1eDhX0rtOCWjc /A/ZqPe2pNdxLWa4fbm+/kizTNDdQgc= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-613-pWPxv9W-NpqHHxYh55Bchw-1; Fri, 08 Dec 2023 10:39:53 -0500 X-MC-Unique: pWPxv9W-NpqHHxYh55Bchw-1 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.rdu2.redhat.com [10.11.54.2]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 73A0585A589; Fri, 8 Dec 2023 15:39:52 +0000 (UTC) Received: from [10.22.9.55] (unknown [10.22.9.55]) by smtp.corp.redhat.com (Postfix) with ESMTP id 6862140C6EB9; Fri, 8 Dec 2023 15:39:51 +0000 (UTC) Message-ID: <4cddddc3-699b-44d6-97a4-9964ca2e60b2@redhat.com> Date: Fri, 8 Dec 2023 10:39:50 -0500 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: Modifying isolcpus, nohz_full, and rcu_nocb kernel parameters at runtime Content-Language: en-US To: Gianfranco Dutka Cc: Tejun Heo , Vincent Guittot , linux-kernel@vger.kernel.org, vincent.guittot@linaro.com, Ingo Molnar , Peter Zijlstra , Juri Lelli , Dietmar Eggemann , Steven Rostedt , Ben Segall , Mel Gorman , Daniel Bristot de Oliveira , Valentin Schneider , "Pandruvada, Srinivas" , Frederic Weisbecker References: <76587DD3-2A77-41A3-9807-6AEE4398EBA6@arista.com> <25E6E1E4-DC16-490E-B907-A3236FB9317A@arista.com> From: Waiman Long In-Reply-To: <25E6E1E4-DC16-490E-B907-A3236FB9317A@arista.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 3.4.1 on 10.11.54.2 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 12/8/23 09:18, Gianfranco Dutka wrote: > >> The isolcpus, nohz_full and rcu_nocbs are boot-time kernel >> parameters. I am in the process of improving dynamic CPU isolation at >> runtime. Right now, we are able to do isolcpus=domain with the >> isolated cpuset partition functionality. Other aspects of CPU >> isolation are being looked at with the goal of reducing the gap of >> what one can do at boot time versus what can be done at run time. It >> will certain take time to reach that goal. >> >> Cheers, Longman >> > > Thank you Waiman for the response. It would seem that getting similar > functionality through cgroups/cpusets is the only option at the > moment. Is it completely out of the question to possibly patch the > kernel to modify these parameters at runtime? Or would that entail a > significant change that might not be so trivial to accomplish? For > instance, the solution wouldn’t be as simple as patching the kernel to > make these writeable and then calling the same functions which run at > boot-time when these parameters are originally written? I would say that using cgroup/cpusets is probably the most you can do with dynamic CPU isolation at the moment. OTOH, it may not be a good idea to have more than one way of doing the same thing as it will lead to code duplication and inconsistency. I don't think it is that easy to make CPU isolation fully dynamic and we must be careful not to introduce any regression. Cheers, Longman