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=-3.9 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,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 760EAC2D0A3 for ; Thu, 29 Oct 2020 13:08:23 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 08F3C2075E for ; Thu, 29 Oct 2020 13:08:22 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=suse.com header.i=@suse.com header.b="qB5H84Ro" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726559AbgJ2NIW (ORCPT ); Thu, 29 Oct 2020 09:08:22 -0400 Received: from mx2.suse.de ([195.135.220.15]:59432 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725554AbgJ2NIV (ORCPT ); Thu, 29 Oct 2020 09:08:21 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1603976899; 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: in-reply-to:in-reply-to:references:references; bh=qW8sAaNoNwfxzYhk+EkdOmpVblS2Sq1VgsLtN6wfi/U=; b=qB5H84Ro4kMRHNMfnMv0jg/PKVI4gMgv8QZJU+uFc7jqamugdPOHIFKYqNTKKuNiNbFoRF OO47fBqgC/Yo9GR+wLIiKMDJj+SifNWtVTNUHHlIH28feimEdIQP3MULwTm4s9up4YCGLs uagj0sYwd14Pyi3E+38Rhnzzu6JwVOo= Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id C7D36B8F3; Thu, 29 Oct 2020 13:08:19 +0000 (UTC) Date: Thu, 29 Oct 2020 14:08:18 +0100 From: Petr Mladek To: Thomas Gleixner Cc: "Zhang, Qiang" , "tj@kernel.org" , "akpm@linux-foundation.org" , "linux-mm@kvack.org" , "linux-kernel@vger.kernel.org" Subject: Re: [PATCH v2] kthread_worker: re-set CPU affinities if CPU come online Message-ID: <20201029130818.GC16774@alley> References: <20201028073031.4536-1-qiang.zhang@windriver.com> <874kme21nv.fsf@nanos.tec.linutronix.de> <871rhi1z7j.fsf@nanos.tec.linutronix.de> <874kmdfndd.fsf@nanos.tec.linutronix.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <874kmdfndd.fsf@nanos.tec.linutronix.de> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu 2020-10-29 09:27:26, Thomas Gleixner wrote: > The expected semantics of a cpu bound kthread_worker are completely > unclear and undocumented. This needs to be fixed first and once this is > established and agreed on then the gaps in the implementation can be > closed. I thought about some sane semantic and it goes down to the following problem: The per-CPU kthread workers are created by explicitly calling kthread_create_worker_on_cpu() on each CPU. The API does _not_ store the information how to start the worker. As a result, it is not able to start a new one when the CPU goes online "for the first time". I mean when the CPU was offline when the API user created the workers. It means that the API user is responsible for handling CPU hotplug on its own. We probably should just document it and do nothing else [*] Alternative solution would be to extend the API and allow to create kthread_worker on each online CPU. It would require to store parameters needed to create the kthread only new online CPUs. Then we might think about some sane semantic for CPU hotplug. Well, it might be hard to define a sane semantic unless there are more users of the API. So, I tend to keep it simple and just document the status quo. Any ideas? [*] IMHO, it does not even make sense to manipulate the affinity. It would just give a false feeling that it is enough. Best Regards, Petr