Received: by 2002:a17:90a:1609:0:0:0:0 with SMTP id n9csp2113297pja; Thu, 26 Mar 2020 09:53:51 -0700 (PDT) X-Google-Smtp-Source: ADFU+vtPa7KmBmdYxhI6UPOhfGMjs6LOHS9qt4pZf9NX4ooVC8YWU/MOK+LaQC/l7g4XjX9UEj+L X-Received: by 2002:a9d:3d65:: with SMTP id a92mr397170otc.326.1585241631188; Thu, 26 Mar 2020 09:53:51 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1585241631; cv=none; d=google.com; s=arc-20160816; b=IuFDEu9V4ZSyN8PWUl6vG8RL1geqKKqqkKUgbEefylG/mHdDj2htKiLTJq5cTfULtz YFaEc3vSxo0hM1hPv0nxdlzDh3cV5yiw/GqaMYK8qn7ZdWuFSpky/F2HXBqXZNdGnuE+ MBfk2xZtmnlS7NMH4sUj0r6ErsexUS7eaEy/Z1mCzfLyO5Rn36CZVUyUHm30RfSd87aH hmmBd6XLmzP2Z9s/riyMVO+fvBCEW7ywl/avy/IxB7GSHRi/0N2qWQGqse/QFhKsJFkE H1PGsVfYTXAP4oJYjJ9DtocoI0d8PJwLx0prhsW3cbu0ieIf22GV6VHwIkshJBdpZ8nV iFHQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature; bh=CRU0gjlVJJCmILa/9nLw3B8l9TRzoo3v9p6/3NkRRdE=; b=s9qRn5ZtOsSFtGsKq9MFmlvQa8tg4FgtK6b3fcabDUqxHsR67lwEDBiPXsYDvBTT8s 7bsuZjSlDeq7wno3xK+1+RnmFjjAHln6PKZX286wlZVYUJvK74fweCBxG9eF2pnv0y9h yRq2ILMvwz7s2B7UjZX0MtM6CyTzE5BlzBPl0WayPN1dH5wVxC+10gLUxgb+YTy8U6lX TMBjCkIXFq/qmz+ZJcu+ehR4viLRxATw8CV7wZeKYN5n9rE9D1iNZBm6GfGBtsnn4B1k qI1l71PZ39kAwb1eNyhbJ40HevznzaJye+51WA4LWkZUjW5jRaA+b8hXxzYuVknWLH/u H6Jw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=NEtNSQ23; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id e11si612282ooq.30.2020.03.26.09.53.31; Thu, 26 Mar 2020 09:53:51 -0700 (PDT) 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; dkim=pass header.i=@kernel.org header.s=default header.b=NEtNSQ23; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727026AbgCZQwn (ORCPT + 99 others); Thu, 26 Mar 2020 12:52:43 -0400 Received: from mail.kernel.org ([198.145.29.99]:57282 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726163AbgCZQwn (ORCPT ); Thu, 26 Mar 2020 12:52:43 -0400 Received: from localhost (lfbn-ncy-1-985-231.w90-101.abo.wanadoo.fr [90.101.63.231]) (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 23C0C20719; Thu, 26 Mar 2020 16:52:41 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1585241562; bh=2G4ysWt8UU1fD4eqylVATl6MWP61iPD641BVzKBSHos=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=NEtNSQ23qndX+CxYerr0NutiGyJtfydmqBwDEjNcoYWuvG3U07qF1TXPQG28EL2sq UScR3sgJ5A1MvImx950FEVoqaPQTyCl3xyZWnvtr3xOrGp2WoZpNrZUIbbE8CgfSU+ 4CtagKo0V1t3EuqrNBuRfp4HPxtfZbhfexYefPEs= Date: Thu, 26 Mar 2020 17:52:40 +0100 From: Frederic Weisbecker To: Marcelo Tosatti Cc: Thomas Gleixner , Chris Friesen , linux-kernel@vger.kernel.org, Christoph Lameter , Jim Somerville , Andrew Morton , Frederic Weisbecker , Peter Zijlstra Subject: Re: [PATCH v2] isolcpus: affine kernel threads to specified cpumask Message-ID: <20200326165239.GD3946@lenoir> References: <20200323135414.GA28634@fuller.cnet> <87k13boxcn.fsf@nanos.tec.linutronix.de> <87imiuq0cg.fsf@nanos.tec.linutronix.de> <20200324152016.GA25422@fuller.cnet> <20200325002956.GC20223@lenoir> <20200325114736.GA17165@fuller.cnet> <20200326162002.GA3946@lenoir> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200326162002.GA3946@lenoir> User-Agent: Mutt/1.9.4 (2018-02-28) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Mar 26, 2020 at 05:20:05PM +0100, Frederic Weisbecker wrote: > On Wed, Mar 25, 2020 at 08:47:36AM -0300, Marcelo Tosatti wrote: > > > > Hi Frederic, > > > > On Wed, Mar 25, 2020 at 01:30:00AM +0100, Frederic Weisbecker wrote: > > > On Tue, Mar 24, 2020 at 12:20:16PM -0300, Marcelo Tosatti wrote: > > > > > > > > This is a kernel enhancement to configure the cpu affinity of kernel > > > > threads via kernel boot option isolcpus=no_kthreads,, > > > > > > > > When this option is specified, the cpumask is immediately applied upon > > > > thread launch. This does not affect kernel threads that specify cpu > > > > and node. > > > > > > > > This allows CPU isolation (that is not allowing certain threads > > > > to execute on certain CPUs) without using the isolcpus=domain parameter, > > > > making it possible to enable load balancing on such CPUs > > > > during runtime (see > > > > > > > > Note-1: this is based off on Wind River's patch at > > > > https://github.com/starlingx-staging/stx-integ/blob/master/kernel/kernel-std/centos/patches/affine-compute-kernel-threads.patch > > > > > > > > Difference being that this patch is limited to modifying > > > > kernel thread cpumask: Behaviour of other threads can > > > > be controlled via cgroups or sched_setaffinity. > > > > > > > > Note-2: MontaVista's patch was based off Christoph Lameter's patch at > > > > https://lwn.net/Articles/565932/ with the only difference being > > > > the kernel parameter changed from kthread to kthread_cpus. > > > > > > > > Signed-off-by: Marcelo Tosatti > > > > > > I'm wondering, why do you need such a boot shift at all when you > > > can actually affine kthreads on runtime? > > > > New, unbound kernel threads inherit the cpumask of kthreadd. > > > > Therefore there is a race between kernel thread creation > > and affine. > > > > If you know of a solution to that problem, that can be used instead. > > Well, you could first set the affinity of kthreadd and only then the affinity > of the others. But I can still imagine some tiny races with fork(). Ah forget that, I missed the part in kthread_create_on_node(). Thanks.