Received: by 2002:a05:6a10:eb17:0:0:0:0 with SMTP id hx23csp197028pxb; Thu, 2 Sep 2021 23:29:45 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwlCHAkky65ZD5n5tOVhBmV4NpDKFnmDkRDssdr53YznDzv4GJl2C17dkwabE0pswHr7SVa X-Received: by 2002:a05:6602:2e13:: with SMTP id o19mr1868466iow.9.1630650585019; Thu, 02 Sep 2021 23:29:45 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1630650585; cv=none; d=google.com; s=arc-20160816; b=lZeV6SmUH23fbI1ceSS01iJfpZxPaNHeCax+QoI5B+V0/+pC78ivDXUkR42x/xlugy QfnPwM6dBrUtbRxc8RnGJGcZ2/+SrKtDAJXNtAqWHYR5muY7tX00/81Jjj3h8OP3oauo kPLJ7Nl5uMfBIPP7Up9xlFqAKPtfyFL6A16yCGrbe75M3emV3BwOlR2KwQ2KoZcmdtSt AbaxoQIJMx41AYK8B2YmF2SMLlnysG2vbniirce07k62UiKasHv2ts0dk4bhCDdv4e3R FCLsA2xQSMeVJFHDjTr89/+LdnOrJ8lMeYYpzQ7ZRScTa5mQpF2VlMLVYNHWMsBFoiyW pZsA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:message-id:date:references :in-reply-to:subject:cc:to:dkim-signature:dkim-signature:from; bh=Oj03gZFgBKlneXTLuFlpjosq+qsCnLlz6Tsf57RrU6U=; b=dtezPtvWLbs6ZdXri6Ztph8QuMvYvdv83wB4l5O0nE0+ByqlOlnPKBY+4dMU1l42hY KuwBK2b17LX3lNfYNqSU37vzGoeGPPzryV+OHO64l/Xd62OmG0SkUR5mTgTpUcJ0fcrs WrcNaie44edvQExW/9aYTUJLvuZFXpX3Y83p1dbVFWEheHQk1H6gtZjeYBQyVk5fZSIO X6eguTn+8i2CxucnbXYN+KAU5HDkBtj4PQWg6EjenYTVUPqREAkizS0+QnwbuUPCUoRB 9j86SENhJNxqLQqeBY/UbdK/Isdn46l2lj6AtSZpWTfh9qI4Sp1Or+rIkeQMzVS2e6R6 wdiA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linutronix.de header.s=2020 header.b=UxCO301d; dkim=neutral (no key) header.i=@linutronix.de; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=linutronix.de Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id x11si4604012ion.51.2021.09.02.23.29.33; Thu, 02 Sep 2021 23:29:45 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@linutronix.de header.s=2020 header.b=UxCO301d; dkim=neutral (no key) header.i=@linutronix.de; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=linutronix.de Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235706AbhICG2B (ORCPT + 99 others); Fri, 3 Sep 2021 02:28:01 -0400 Received: from Galois.linutronix.de ([193.142.43.55]:48570 "EHLO galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230128AbhICG2A (ORCPT ); Fri, 3 Sep 2021 02:28:00 -0400 From: Thomas Gleixner DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1630650419; 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=Oj03gZFgBKlneXTLuFlpjosq+qsCnLlz6Tsf57RrU6U=; b=UxCO301dAkvC1O6CEFSs9BDF/EHWaGq74xuu22aOSKeDxyiG15pXQ8UdzD+GMCWD7qI2fy 1okhBIFuVJXPh18K9KmQXoAZmndIa7mAif+MJIC0m77cZqFlZPWn0jCziqOparFdWWg8Ln OTKZ0Nv0FbxBGulDLACNIMI0f4i6IYRnxCcFGnsSLdcYXxlfncPuartw/17m5N75tPNhQ3 vWxLcBKMUq8fVXX9LT31xa70mOlZz9Wf50c3274w7i87yNQG9bCqGZCFPeEn6k8HsBsNj5 9y7uRrO8AIlOopb20+7C6qICj3fvhfZWyMpqG4VZYpTx4vzk3bAzpG67V9Z+ag== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1630650419; 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=Oj03gZFgBKlneXTLuFlpjosq+qsCnLlz6Tsf57RrU6U=; b=w5/p55F8WBEP8YihYst5Fz3ycPHwF6J50NOGKBuCgwVsb5tcD0J8VxMchQOyY3ysNKvBlx dcqIrcLg4xwxFrCg== To: Dave Chinner , "Darrick J. Wong" Cc: Linus Torvalds , Dennis Zhou , Tejun Heo , linux-fsdevel , linux-xfs , Linux Kernel Mailing List , Eric Sandeen , Christoph Hellwig Subject: Re: [GIT PULL] xfs: new code for 5.15 In-Reply-To: <20210902223545.GA1826899@dread.disaster.area> References: <20210831211847.GC9959@magnolia> <20210902174311.GG9942@magnolia> <20210902223545.GA1826899@dread.disaster.area> Date: Fri, 03 Sep 2021 08:26:58 +0200 Message-ID: <87a6kub2dp.ffs@tglx> MIME-Version: 1.0 Content-Type: text/plain Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Dave, On Fri, Sep 03 2021 at 08:35, Dave Chinner wrote: > On Thu, Sep 02, 2021 at 10:43:11AM -0700, Darrick J. Wong wrote: > The part I dislike most about it is that we have to modify a header > file that triggers full kernel rebuilds. Managing patch stacks and > branches where one of them modifies such a header file means quick, > XFS subsystem only kernel rebuilds are a rare thing... If you don't care about ordering, you can avoid touching the global header completely. The dynamic state ranges in PREPARE and ONLINE provide exactly what you want. It's documented. > That said, I'm all for a better interface to the CPU hotplug > notifications. THe current interface is ... esoteric and to What's so esoteric about: state = cpuhp_setup_state(CPUHP_BP_PREPARE_DYN, "xfs:prepare", func1, func2); state = cpuhp_setup_state(CPUHP_AP_ONLINE_DYN, "xfs:online", func3, func4); Only if you care about callback ordering vs. other subsystems, then adding the state in the global header is required. It's neither the end of the world, nor is it rocket science and requires expert knowledge to do so. > understand how to use it effectively requires becoming a CPU hotplug > expert. https://www.kernel.org/doc/html/latest/core-api/cpu_hotplug.html If there is something missing in that documentation which makes you think you need to become a CPU hotplug expert, please let me know. I'm happy to expand that document. > There's something to be said for the simplicity of the old > register_cpu_notifier() interface we used to have... There is a lot to be said about it. The simplicity of it made people do the most hillarious things to deal with: - Ordering issues including build order dependencies - Asymetry between bringup and teardown - The inability to test state transitions - .... Back then when we converted the notifier mess 35 of ~140 hotplug notifiers (i.e. ~25%) contained bugs of all sorts. Quite some of them were caused by the well understood simplicity of the hotplug notifier mechanics. I'm surely not missing any of that. Thanks, tglx