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 1A6B7C4332F for ; Tue, 12 Dec 2023 18:48:59 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231747AbjLLSsu (ORCPT ); Tue, 12 Dec 2023 13:48:50 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:41102 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232815AbjLLSst (ORCPT ); Tue, 12 Dec 2023 13:48:49 -0500 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 4B2F6CE for ; Tue, 12 Dec 2023 10:48:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1702406934; 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=MlLCC9svnl50XjxVcSD4zVNUv5xUFa+AQPJOzT5s4w8=; b=FdKLRMypnOgKVVvCPpTb9mvqQa9mgTPlx6AAhq0i0nfy3xtpKoZJepqXa6aUq/M01qVtqG 3qWtpFGic3N0cy9JJzOzZpa1LlVyjAOGXD3pQzCuD4GzpdlgIG2mQfzkA5boDlxD6P7Fnv oyyZbKdO3TNoKqL4VWDUJ3mhkCKIFKU= 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-302-IZAOMrK8PY61ihlC7Jnu5Q-1; Tue, 12 Dec 2023 13:48:48 -0500 X-MC-Unique: IZAOMrK8PY61ihlC7Jnu5Q-1 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.rdu2.redhat.com [10.11.54.4]) (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 157F4833946; Tue, 12 Dec 2023 18:48:48 +0000 (UTC) Received: from lorien.usersys.redhat.com (unknown [10.22.9.61]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 30DE82026D66; Tue, 12 Dec 2023 18:48:47 +0000 (UTC) Date: Tue, 12 Dec 2023 13:48:45 -0500 From: Phil Auld To: Frederic Weisbecker Cc: Gianfranco Dutka , Waiman Long , 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" Subject: Re: Modifying isolcpus, nohz_full, and rcu_nocb kernel parameters at runtime Message-ID: <20231212184845.GA392327@lorien.usersys.redhat.com> References: <76587DD3-2A77-41A3-9807-6AEE4398EBA6@arista.com> <25E6E1E4-DC16-490E-B907-A3236FB9317A@arista.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Scanned-By: MIMEDefang 3.4.1 on 10.11.54.4 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Dec 12, 2023 at 02:27:56PM +0100 Frederic Weisbecker wrote: > On Fri, Dec 08, 2023 at 09:18:53AM -0500, 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? > > As for nohz_full (which implies rcu_nocb), it's certainly possible to make it > tunable at runtime via cpusets. If people really want it, I'm willing to help. That is certainly where we'd like to end up. The ask for this is coming from our container management side so cpusets would fit that well (along with the isolation stuff Waiman has been working on). Thanks, Phil > > Thanks. > --