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 DBF20C55179 for ; Thu, 29 Oct 2020 13:08:23 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 3BCD620790 for ; Thu, 29 Oct 2020 13:08:23 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=suse.com header.i=@suse.com header.b="qB5H84Ro" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 3BCD620790 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=suse.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 4CA0C6B0068; Thu, 29 Oct 2020 09:08:22 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 479ED6B006C; Thu, 29 Oct 2020 09:08:22 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3904F6B006E; Thu, 29 Oct 2020 09:08:22 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0088.hostedemail.com [216.40.44.88]) by kanga.kvack.org (Postfix) with ESMTP id 0B3256B0068 for ; Thu, 29 Oct 2020 09:08:21 -0400 (EDT) Received: from smtpin05.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id A298133C4 for ; Thu, 29 Oct 2020 13:08:21 +0000 (UTC) X-FDA: 77424991602.05.dime35_5e05fe82728d Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin05.hostedemail.com (Postfix) with ESMTP id 7E0051826B6BF for ; Thu, 29 Oct 2020 13:08:21 +0000 (UTC) X-HE-Tag: dime35_5e05fe82728d X-Filterd-Recvd-Size: 3337 Received: from mx2.suse.de (mx2.suse.de [195.135.220.15]) by imf10.hostedemail.com (Postfix) with ESMTP for ; Thu, 29 Oct 2020 13:08:20 +0000 (UTC) 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> X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: 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