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.8 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,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 A28B8C4363A for ; Mon, 26 Oct 2020 16:53:19 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 13071223EA for ; Mon, 26 Oct 2020 16:53:18 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="B1PoPwPm" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 13071223EA Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 25A9A6B006E; Mon, 26 Oct 2020 12:53:18 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 209E16B0070; Mon, 26 Oct 2020 12:53:18 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 05EA76B0071; Mon, 26 Oct 2020 12:53:18 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0138.hostedemail.com [216.40.44.138]) by kanga.kvack.org (Postfix) with ESMTP id CA7D06B006E for ; Mon, 26 Oct 2020 12:53:17 -0400 (EDT) Received: from smtpin04.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 756C2180AD815 for ; Mon, 26 Oct 2020 16:53:17 +0000 (UTC) X-FDA: 77414672034.04.shelf47_461308827275 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin04.hostedemail.com (Postfix) with ESMTP id 461408004CFA for ; Mon, 26 Oct 2020 16:53:17 +0000 (UTC) X-HE-Tag: shelf47_461308827275 X-Filterd-Recvd-Size: 4884 Received: from mail-qv1-f67.google.com (mail-qv1-f67.google.com [209.85.219.67]) by imf33.hostedemail.com (Postfix) with ESMTP for ; Mon, 26 Oct 2020 16:53:16 +0000 (UTC) Received: by mail-qv1-f67.google.com with SMTP id t20so4599830qvv.8 for ; Mon, 26 Oct 2020 09:53:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=tRGzOr0ebxa8PA89MZHTDFpEs7q7Dz3b2th/oGGJY/I=; b=B1PoPwPmVENh9APWJE9yBymBpwfHajobryt05CnlXJl+v5q5n7ClEUHus5RDVAmF/b 5qzeta/rkT/M9pbNKoD/6DJNpqFfhYeq5UDdD+hLk/xtwoYXGyOGUqgBmX+8TXg51ozK cpJsw52UzryS42fK2g71D3NDf6X7i9DEyWm7ipdzAjKevscnD560PcDVd0arGY3lpg4K 4+u3bjBKcFczN6wqnSq4ymxRTp5ZMfC/jLhcT/1qJ5pUVVKnWk79h53OFWBC5fmHCrfG F/Jz1pTm7BW6fSXLHT55tlnNZvSeOqBXcfTlH2LVRJso4A4hnMOpdxq/9E75vX5qKf7X 9+qg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition:in-reply-to; bh=tRGzOr0ebxa8PA89MZHTDFpEs7q7Dz3b2th/oGGJY/I=; b=mxDVpJIk9ETQUHoSGm8mDF7nusnxys8r23Ex21LBbffBlMUJ10v9HwIDJeHCjVgIrG G/fGN2jyUwkR2u+DLa5IKM7vpGk2SK2b6VCwInAdgkChm9pmvpO3nmscFUOmeiaywCma KwJsVc7nUoXbvldGV4OS+rRaoGSH6ZMIWhRIhS3okGjwT/zdzeuy17zu5xaeb/h3hl5r 4fbEBkXO5DRo6f8SUbkyqjgXzFL++fecYKIZ1qhlMRo+qXotLsz1csKZm5CJnDRdlVTw Ks3/Xr0W4aEeNf1PLCeKlxM3SLgaJUGV5Hfx+ktzI6bAPo5ms6ZKUzlcEKgmu2dJit0n T2hQ== X-Gm-Message-State: AOAM5318cPZMKpNUSKpFhheGVO/Ryz70kuK+ZF5BlyjLAGLYpacAksAJ mSySfaJUJNOtUkEdFPovXfE= X-Google-Smtp-Source: ABdhPJzT9a0QQE8CYV+cIfwLyXKbu3bBCHITSkRTe6isI7Sk32lRpJw2KKqpaWDA5kE8Wc6XBP5+mA== X-Received: by 2002:a0c:a482:: with SMTP id x2mr18539898qvx.47.1603731195996; Mon, 26 Oct 2020 09:53:15 -0700 (PDT) Received: from localhost ([2620:10d:c091:480::1:c37]) by smtp.gmail.com with ESMTPSA id d188sm7141118qkb.10.2020.10.26.09.53.14 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 26 Oct 2020 09:53:14 -0700 (PDT) Date: Mon, 26 Oct 2020 12:53:11 -0400 From: Tejun Heo To: Petr Mladek Cc: qiang.zhang@windriver.com, akpm@linux-foundation.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org Subject: Re: [PATCH] kthread_worker: re-set CPU affinities if CPU come online Message-ID: <20201026165311.GA97873@mtj.duckdns.org> References: <20201026065213.30477-1-qiang.zhang@windriver.com> <20201026135011.GC73258@mtj.duckdns.org> <20201026164555.GA7544@alley> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20201026164555.GA7544@alley> 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: Hello, Petr. On Mon, Oct 26, 2020 at 05:45:55PM +0100, Petr Mladek wrote: > > I don't think this works. The kthread may have changed its binding while > > running using set_cpus_allowed_ptr() as you're doing above. Besides, when a > > cpu goes offline, the bound kthread can fall back to other cpus but its cpu > > mask isn't cleared, is it? > > If I get it correctly, select_fallback_rq() calls > do_set_cpus_allowed() explicitly or in cpuset_cpus_allowed_fallback(). > It seems that the original mask gets lost. Oh, I see. > It would make sense to assume that kthread_worker API will take care of > the affinity when it was set by kthread_create_worker_on_cpu(). I was for some reason thinking this was for all kthreads. Yeah, for kthread_workers it does make sense. > But is it safe to assume that the work can be safely proceed also > on another CPU? We should probably add a warning into > kthread_worker_fn() when it detects wrong CPU. Per-cpu workqueues behave like that too. When the CPU goes down, per-cpu workers on that CPU are unbound and may run anywhere. They get rebound when CPU comes back up. > BTW: kthread_create_worker_on_cpu() is currently used only by > start_power_clamp_worker(). And it has its own CPU hotplug > handling. The kthreads are stopped and started again > in powerclamp_cpu_predown() and powerclamp_cpu_online(). And users which have hard dependency on CPU binding are expected to implement hotplug events so that e.g. per-cpu work items are flushed when CPU goes down and scheduled back when it comes back online. There are pros and cons to the current workqueue behavior but it'd be a good idea to keep kthread_worker's behavior in sync. > I havn't checked all details yet. But in principle, the patch looks > sane to me. Yeah, agreed. Thanks. -- tejun