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 X-Spam-Level: X-Spam-Status: No, score=-7.5 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 7BBDEC07E9B for ; Mon, 19 Jul 2021 13:26:55 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 66A9161164 for ; Mon, 19 Jul 2021 13:26:55 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237847AbhGSMqO (ORCPT ); Mon, 19 Jul 2021 08:46:14 -0400 Received: from mail.kernel.org ([198.145.29.99]:45484 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S237832AbhGSMqL (ORCPT ); Mon, 19 Jul 2021 08:46:11 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id 3A45560E0B; Mon, 19 Jul 2021 13:26:51 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1626701211; bh=MdzRIJoouHXqMOtbajXpawm8OypsDYkx33XVamI0/hY=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=rhklKodmBO5Zh8hsh6Lm1OaJsNSNkS9pBiy60DLODIQOI0q/pKqa+olpvQtujVc9R Zisa2vB6p7u3SrK/W1aES6nSLhsDIIHJ8m/4JeuwuoIC7YXQiA+5BnT/xFelSNKVy5 91i6vjeRsLb4RkmlZomo5yI8EMh96/kFC0xVNT0tkGJXERpPjLw3jd3gRGI4cA/YQi vvBR0gHAPOOwZ3vMEqAkX8p5gnRlOGsiVavlElvhuQZ1Cu/TIsNDNqZjhAs+WvpKId Agb08UgkwGzV/XozIs8eCAWIrZhFkS28+N+CFELamobphtSNMOTaVXa/3g9M20vsir 7p7U6y2qyUWyw== Date: Mon, 19 Jul 2021 15:26:49 +0200 From: Frederic Weisbecker To: Marcelo Tosatti Cc: LKML , Tejun Heo , Peter Zijlstra , Juri Lelli , Alex Belits , Nitesh Lal , Thomas Gleixner , Nicolas Saenz , Christoph Lameter , Zefan Li , cgroups@vger.kernel.org Subject: Re: [RFC PATCH 6/6] cpuset: Add cpuset.isolation_mask file Message-ID: <20210719132649.GB116346@lothringen> References: <20210714135420.69624-1-frederic@kernel.org> <20210714135420.69624-7-frederic@kernel.org> <20210714163157.GA140679@fuller.cnet> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210714163157.GA140679@fuller.cnet> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Jul 14, 2021 at 01:31:57PM -0300, Marcelo Tosatti wrote: > On Wed, Jul 14, 2021 at 03:54:20PM +0200, Frederic Weisbecker wrote: > > Add a new cpuset.isolation_mask file in order to be able to modify the > > housekeeping cpumask for each individual isolation feature on runtime. > > In the future this will include nohz_full, unbound timers, > > unbound workqueues, unbound kthreads, managed irqs, etc... > > > > Start with supporting domain exclusion and CPUs passed through > > "isolcpus=". > > It is possible to just add return -ENOTSUPPORTED for the features > whose support is not present? Maybe, although that looks like a specialized error for corner cases. > > > > CHECKME: Should we have individual cpuset.isolation.$feature files for > > each isolation feature instead of a single mask file? > > Yes, guess that is useful, for example due to the -ENOTSUPPORTED > comment above. > > > Guarantees on updates > ===================== > > Perhaps start with a document with: > > On return to the write to the cpumask file, what are the guarantees? > > For example, for kthread it is that any kernel threads from that point > on should start with the new mask. Therefore userspace should > respect the order: > > 1) Change kthread mask. > 2) Move threads. > Yep. > Updates to interface > ==================== > > Also, thinking about updates to the interface (which today are one > cpumask per isolation feature) might be useful. What can happen: > > 1) New isolation feature is added, feature name added to the interface. > > Userspace must support new filename. If not there, then thats an > old kernel without support for it. > > 2) If an isolation feature is removed, a file will be gone. What should > be the behaviour there? Remove the file? (userspace should probably > ignore the failure in that case?) (then features names should not be > reused, as that can confuse #1 above). Heh, yeah that's complicated. I guess we should use one flag per file as that fits well within the current cpuset design. But we must carefully choose the new files to make sure they have the least chances to be useless in the long term. > Or maybe have a versioned scheme? I suspect we should avoid that at all costs :-) Thanks!