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 8594BC636C9 for ; Mon, 19 Jul 2021 13:57:33 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 67B85610F7 for ; Mon, 19 Jul 2021 13:57:33 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S240669AbhGSNQv (ORCPT ); Mon, 19 Jul 2021 09:16:51 -0400 Received: from mail.kernel.org ([198.145.29.99]:48016 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S237309AbhGSNQu (ORCPT ); Mon, 19 Jul 2021 09:16:50 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id 2F4DD61006; Mon, 19 Jul 2021 13:57:30 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1626703050; bh=+gVq/NFsqZiiPUEMlRTEwLOqGw7ioAT+zNXkcTJwXSw=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=oDyz5R+TBMFxLUUYo1IoQTxZpDh1twoMsHUmfL0NQkHCmV9hhtBs/kvJ0JI7WZIaa mddj4GV4kxWWR/KJi+/bK8N4FPB9OD0RMAFdfFnTfIYY+47oZ9zCli0GHBv3rm5gRy aRyUECiBI9Vhem5Lfq5o09JOb7d7DkR7ON+ceouOITetcG7rM2405gaH/+vX3Be953 5Bm3FcH0mX1Ek1rGpB+qXz3ZCwCHcdZlqyr472clqvGzJKs/+iwQhi3pLIb/9xLqKW 0B4C+rb2rxI+Cyx85ZUR3NwT5A37yIMHuNkGO1kmelIzRBkNARj2916Fkou0EjXd/O tu1JH1vqPyxKg== Date: Mon, 19 Jul 2021 15:57:28 +0200 From: Frederic Weisbecker To: Waiman Long Cc: LKML , Tejun Heo , Peter Zijlstra , Juri Lelli , Alex Belits , Nitesh Lal , Thomas Gleixner , Nicolas Saenz , Christoph Lameter , Marcelo Tosatti , Zefan Li , cgroups@vger.kernel.org Subject: Re: [RFC PATCH 0/6] cpuset: Allow to modify isolcpus through cpuset Message-ID: <20210719135728.GD116346@lothringen> References: <20210714135420.69624-1-frederic@kernel.org> <8ea7a78f-948e-75e8-1c4f-59b349c858f6@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8ea7a78f-948e-75e8-1c4f-59b349c858f6@redhat.com> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Jul 16, 2021 at 02:02:50PM -0400, Waiman Long wrote: > On 7/14/21 9:54 AM, Frederic Weisbecker wrote: > > The fact that "isolcpus=" behaviour can't be modified at runtime is an > > eternal source of discussion and debate opposing a useful feature against > > a terrible interface. > > > > I've long since tried to figure out a proper way to control this at > > runtime using cpusets, which isn't easy as a boot time single cpumask > > is difficult to map to a hierarchy of cpusets that can even overlap. > > I have a cpuset patch that allow disabling of load balancing in a cgroup-v2 > setting: > > https://lore.kernel.org/lkml/20210621184924.27493-1-longman@redhat.com/ > > The idea of cpuset partition is that there will be no overlap of cpus in > different partitions. So there will be no confusion whether a cpu is > load-balanced or not. Oh ok I missed that, time for me to check your patchset. Thanks! > > > > > The idea here is to map the boot-set isolation behaviour to any cpuset > > directory whose cpumask is a subset of "isolcpus=". I let you browse > > for details on the last patch. > > > > Note this is still WIP and half-baked, but I figured it's important to > > validate the interface early. > > Using different cpumasks for different isolated properties is the easy part. > The hard part is to make different subsystems to change their behavior as > the isolation masks change dynamically at run time. Currently, they check > the housekeeping cpumask only at boot time or when certain events happen. > > Cheers, > Longman > > From mboxrd@z Thu Jan 1 00:00:00 1970 From: Frederic Weisbecker Subject: Re: [RFC PATCH 0/6] cpuset: Allow to modify isolcpus through cpuset Date: Mon, 19 Jul 2021 15:57:28 +0200 Message-ID: <20210719135728.GD116346@lothringen> References: <20210714135420.69624-1-frederic@kernel.org> <8ea7a78f-948e-75e8-1c4f-59b349c858f6@redhat.com> Mime-Version: 1.0 Return-path: DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1626703050; bh=+gVq/NFsqZiiPUEMlRTEwLOqGw7ioAT+zNXkcTJwXSw=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=oDyz5R+TBMFxLUUYo1IoQTxZpDh1twoMsHUmfL0NQkHCmV9hhtBs/kvJ0JI7WZIaa mddj4GV4kxWWR/KJi+/bK8N4FPB9OD0RMAFdfFnTfIYY+47oZ9zCli0GHBv3rm5gRy aRyUECiBI9Vhem5Lfq5o09JOb7d7DkR7ON+ceouOITetcG7rM2405gaH/+vX3Be953 5Bm3FcH0mX1Ek1rGpB+qXz3ZCwCHcdZlqyr472clqvGzJKs/+iwQhi3pLIb/9xLqKW 0B4C+rb2rxI+Cyx85ZUR3NwT5A37yIMHuNkGO1kmelIzRBkNARj2916Fkou0EjXd/O tu1JH1vqPyxKg== Content-Disposition: inline In-Reply-To: <8ea7a78f-948e-75e8-1c4f-59b349c858f6-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> List-ID: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Waiman Long Cc: LKML , Tejun Heo , Peter Zijlstra , Juri Lelli , Alex Belits , Nitesh Lal , Thomas Gleixner , Nicolas Saenz , Christoph Lameter , Marcelo Tosatti , Zefan Li , cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org On Fri, Jul 16, 2021 at 02:02:50PM -0400, Waiman Long wrote: > On 7/14/21 9:54 AM, Frederic Weisbecker wrote: > > The fact that "isolcpus=" behaviour can't be modified at runtime is an > > eternal source of discussion and debate opposing a useful feature against > > a terrible interface. > > > > I've long since tried to figure out a proper way to control this at > > runtime using cpusets, which isn't easy as a boot time single cpumask > > is difficult to map to a hierarchy of cpusets that can even overlap. > > I have a cpuset patch that allow disabling of load balancing in a cgroup-v2 > setting: > > https://lore.kernel.org/lkml/20210621184924.27493-1-longman-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org/ > > The idea of cpuset partition is that there will be no overlap of cpus in > different partitions. So there will be no confusion whether a cpu is > load-balanced or not. Oh ok I missed that, time for me to check your patchset. Thanks! > > > > > The idea here is to map the boot-set isolation behaviour to any cpuset > > directory whose cpumask is a subset of "isolcpus=". I let you browse > > for details on the last patch. > > > > Note this is still WIP and half-baked, but I figured it's important to > > validate the interface early. > > Using different cpumasks for different isolated properties is the easy part. > The hard part is to make different subsystems to change their behavior as > the isolation masks change dynamically at run time. Currently, they check > the housekeeping cpumask only at boot time or when certain events happen. > > Cheers, > Longman > >