Received: by 2002:a25:1506:0:0:0:0:0 with SMTP id 6csp4922620ybv; Tue, 11 Feb 2020 06:00:31 -0800 (PST) X-Google-Smtp-Source: APXvYqzVGvoX/T7yUWER8T+CHuO0QGeqdqlotWSE1vrT6pzny+Q3j8Z1tqJRWAivU8+9Yj8Ex5/i X-Received: by 2002:a9d:20c1:: with SMTP id x59mr5493649ota.286.1581429631378; Tue, 11 Feb 2020 06:00:31 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1581429631; cv=none; d=google.com; s=arc-20160816; b=ftWHEJ+eFkEUPjZw7rfP8aTplBb1mcF4ZQFQXMAffoi8KDPezUrR+xPREPYYNNTksP U5ulPro/xqhunLYyxWIRZmGpuYTDhiekg0hTotqTORMD33nOMhiNCuVFjxEkFz6RpikS dC00KWmlPhgsLwRErl8ej5MDMEcVLaOd8c9bw4y579grJ2NhGbyTFYfSERi0mt+sbqhG n8Vfe/5Gig0fDmUb56yHXq120Sz/BZ8YbIAdl1ugQqZztq7vkVj6k6Z0yUKpWMKoY2n+ L2cqCHMirr95Zv5WXFeEUEB1ZgOzzA5hCRCwqmhF6ONf4v1SD3IOVZacbnQXxksygdb4 45jw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:message-id:subject:cc:to:from:date; bh=EBpIUYLokgBN2MsqwGZXLWACtXGjlNbJikYfadKbG+8=; b=NGXglUJuK1NRDQc3Sfmhlvl2T6hYPGVvOPpibl66DEaxMPPKAfJ8X311rnAat/tzWX R/kFumUzhmUl1cfZQKp5qwyh0MJPTdn5mxK2O05kYCKwjsMn/4Udps6QnQjK+AXyZXVc 3nVvmrUJjMFyZgsmigG3ZrjrztUb8mjR0c1ASTdH1c/H/EHnQcpFIyxQbnUQh2T3VwLe NhFNSfVhQTiyxaTJD1mJmTqHLsAJ9mDRqpJZyqKD+udeh+opX/duwJvodIuc8I683zuz Te2i/9k4Ha9Bes0mZ0x13hSds/YcwurLosIsNOQ3kA2XGU0z9CNM5oauQIUZoVzL4eO3 ENZA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id c5si1836563otp.108.2020.02.11.06.00.19; Tue, 11 Feb 2020 06:00:31 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729825AbgBKNyw convert rfc822-to-8bit (ORCPT + 99 others); Tue, 11 Feb 2020 08:54:52 -0500 Received: from mail.kernel.org ([198.145.29.99]:50760 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729598AbgBKNyr (ORCPT ); Tue, 11 Feb 2020 08:54:47 -0500 Received: from gandalf.local.home (cpe-66-24-58-225.stny.res.rr.com [66.24.58.225]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 716F8214DB; Tue, 11 Feb 2020 13:54:45 +0000 (UTC) Date: Tue, 11 Feb 2020 08:54:43 -0500 From: Steven Rostedt To: =?UTF-8?B?546L6LSH?= Cc: Ingo Molnar , Peter Zijlstra , Juri Lelli , Vincent Guittot , Dietmar Eggemann , Ben Segall , Mel Gorman , "open list:SCHEDULER" , Tejun Heo , Li Zefan , Johannes Weiner , cgroups@vger.kernel.org Subject: Re: [RFC] why can't dynamic isolation just like the static way Message-ID: <20200211085443.2a112c03@gandalf.local.home> In-Reply-To: References: X-Mailer: Claws Mail 3.17.3 (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org You forgot to include the cgroup maintainers. -- Steve On Tue, 11 Feb 2020 16:17:34 +0800 王贇 wrote: > Hi, folks > > We are dealing with isolcpus these days and try to do the isolation > dynamically. > > The kernel doc lead us into the cpuset.sched_load_balance, it's fine > to achieve the dynamic isolation with it, however we got problem with > the systemd stuff. > > It's keeping create cgroup with sched_load_balance enabled on default, > while the cpus are overlapped with the isolated ones, which lead into > sched domain rebuild and these cpus become non-isolated. > > We're just looking forward an easy way to dynamic isolate some cpus, > just like the isolation parameter, but sched_load_balance forcing us > to dealing with the management of cgroups, we really don't get the > point in here... > > Why do we have to mix the isolation with cgroups? Why not just provide > a proc entry to read cpumask and rebuild the domains? > > Please let us know if there is any good reason to make the dynamic > isolation in that way, appreciated in advance :-) > > Regards, > Michael Wang