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=-2.7 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED 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 F3632C433E6 for ; Wed, 6 Jan 2021 21:17:58 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id BDB2D2313E for ; Wed, 6 Jan 2021 21:17:58 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726300AbhAFVRm (ORCPT ); Wed, 6 Jan 2021 16:17:42 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:36172 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725788AbhAFVRm (ORCPT ); Wed, 6 Jan 2021 16:17:42 -0500 Received: from mail-io1-xd30.google.com (mail-io1-xd30.google.com [IPv6:2607:f8b0:4864:20::d30]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 06736C061757 for ; Wed, 6 Jan 2021 13:17:02 -0800 (PST) Received: by mail-io1-xd30.google.com with SMTP id u26so4098189iof.3 for ; Wed, 06 Jan 2021 13:17:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=LqnpZZaOgAY4yAAIC3yU2hn9Amq6TciTL0LFzqShfbA=; b=Y8ijcEeM5nuL9Ru39V/RIYZZ4SaD/88k8WrESfGFmXotkW+FeGGCnO7pvS2rwOFYl/ kkuLIztOSX1jI99KJ3SdPBSJ01D0w4JrijmB60Xilq44KvOb2h+gOHgMHHldS2l3uB6Y xSvSiV4UQ3La73/i6aECnPj4Myp2haPjPjzXgRWzDAISBOsP+6t12MIOz3o1VktYQUOE kaD5w67T+2ethvyzIEAMmK1Tt7ROvcjzMAqO8VyhkU1d8kyoLqVUkglRwEomm7bBBsx8 6xYNwU/c8mZ2etEsVtvyaz4IBeGSX0vZ3zJxKolgO0mZtS1lOUDSOkfgC9map+50E5ZP 42Kg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=LqnpZZaOgAY4yAAIC3yU2hn9Amq6TciTL0LFzqShfbA=; b=Ql+a5t2wT2ep4AU8eUxGt2dZ9+jH3vVfR/nZEyfZTV8DaXiSXvU90Dc8NMNvCjb5T5 WonfVFuGkoSKh4f8SkzWtDxoaow8SPc+9WXPhQbIpywvi3rgCRa5AIRjtftv7UGsgoIU pzBw4dkfR0TITB8elWNq45P+oycbrFt9/Gw+lRKEX4xElUcwh2lJACmv12gbfKX59315 57qBruUO4lDTMbqklTmzkHsPIZJzYyp1O6QJYjoFxlx5ntJmapZN0O0QCWvoBcOP+0YN 9lOUFQGQS/8nrNDkThJSssd4ranffbR4wjXDHa1bw2Ie+s59DXWqh8COvGLaUMKOgg0W c0IA== X-Gm-Message-State: AOAM530ys+HXw0da6FT23Mk0oKoie8sMyIMEzCCU6ac9XWEK23Al6twr T8Tcz/Q91n61xxp/prCUw+olRhLQniaOAZeZEFGrk5PD5xHaqg== X-Google-Smtp-Source: ABdhPJxghafYjyj+Y8W59tnCmzWx9h+dy/If4GHa7ylzA6pbBezUs4wlNQDsCnuopPCFzShrV42SAdJNKeGIGw9fwHY= X-Received: by 2002:a02:b042:: with SMTP id q2mr5237158jah.29.1609967821243; Wed, 06 Jan 2021 13:17:01 -0800 (PST) MIME-Version: 1.0 References: <20210106004850.GA11682@paulmck-ThinkPad-P72> <20210106004956.11961-4-paulmck@kernel.org> In-Reply-To: From: Yury Norov Date: Wed, 6 Jan 2021 13:16:50 -0800 Message-ID: Subject: Re: [PATCH RFC cpumask 4/5] cpumask: Add "last" alias for cpu list specifications To: Peter Zijlstra Cc: paulmck@kernel.org, Linux Kernel Mailing List , kernel-team@fb.com, Paul Gortmaker Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Jan 6, 2021 at 1:50 AM Peter Zijlstra wrote: > > On Tue, Jan 05, 2021 at 04:49:55PM -0800, paulmck@kernel.org wrote: > > From: Paul Gortmaker > > > > It seems that a common configuration is to use the 1st couple cores > > for housekeeping tasks, and or driving a busy peripheral that generates > > a lot of interrupts, or something similar. > > > > This tends to leave the remaining ones to form a pool of similarly > > configured cores to take on the real workload of interest to the user. > > > > So on machine A - with 32 cores, it could be 0-3 for "system" and then > > 4-31 being used in boot args like nohz_full=, or rcu_nocbs= as part of > > setting up the worker pool of CPUs. > > > > But then newer machine B is added, and it has 48 cores, and so while > > the 0-3 part remains unchanged, the pool setup cpu list becomes 4-47. > > > > Deployment would be easier if we could just simply replace 31 and 47 > > with "last" and let the system substitute in the actual number at boot; > > a number that it knows better than we do. > > > > No need to have custom boot args per node, no need to do a trial boot > > in order to snoop /proc/cpuinfo and/or /sys/devices/system/cpu - no > > more fencepost errors of using 32 and 48 instead of 31 and 47. > > > > A generic token replacement is used to substitute "last" with the > > number of CPUs present before handing off to bitmap processing. But > > it could just as easily be used to replace any placeholder token with > > any other token or value only known at/after boot. > > Aside from the comments Yury made, on how all this is better in > bitmap_parselist(), how about doing s/last/N/ here? For me something > like: "4-N" reads much saner than "4-last". > > Also, it might make sense to teach all this about core/node topology, > but that's going to be messy. Imagine something like "Core1-CoreN" or > "Nore1-NodeN" to mean the mask all/{Core,Node}0. If you just want to teach bitmap_parselist() to "s/Core0/0-4", I think it's doable if we add a hook to a proper subsystem in bitmap_parselist(). > And that is another feature that seems to be missing from parselist, > all/except. We already support groups in a range. I think it partially covers the proposed all/except. Can you share examples on what you miss?