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 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 3B428C433F5 for ; Thu, 11 Nov 2021 09:36:32 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 1AC44610F8 for ; Thu, 11 Nov 2021 09:36:32 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232611AbhKKJjT (ORCPT ); Thu, 11 Nov 2021 04:39:19 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46258 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230009AbhKKJjS (ORCPT ); Thu, 11 Nov 2021 04:39:18 -0500 Received: from mail-ot1-x335.google.com (mail-ot1-x335.google.com [IPv6:2607:f8b0:4864:20::335]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 9374EC061766 for ; Thu, 11 Nov 2021 01:36:29 -0800 (PST) Received: by mail-ot1-x335.google.com with SMTP id x19-20020a9d7053000000b0055c8b39420bso8090436otj.1 for ; Thu, 11 Nov 2021 01:36:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=FQNotspdE85/ckyfVd22yizASeOICaHxBSL2D6Rwwpw=; b=UpJAsHH3wXt4nQODZVjA9FrGKUqqDF32IatYTS1SYxwoDbaRut+X6zfgkOHGkn0yt0 CNegVOkjnK2sjy9Nms1243+zJFMjwFxKJ0owcLdYwK4/PjI+gpArN+24oajV3xi/bhAy y4ZTyZR4eWiJ2OqOTzZEw2+igo64Nc8xI9URhaWwqZL/ND7O6tYzZtsA/GOBw2sWuoEm +sywwDbjeG7T5ZEbZY9f9HgkehvolqW8JKcnjE2AosQdOyQoLdVupvgtXCV4bh2itKzF r4pIhz+pgijcQhHbDC5rWqcGvaxt/0sD85qniaK0p3CW+j8Sz9/u8rlcxct8jbsPhSNe rQ8A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=FQNotspdE85/ckyfVd22yizASeOICaHxBSL2D6Rwwpw=; b=18F20aD0voU85hbTXZ88TM7yVEWL/Sam8W7d6Hj5tNMhOMWzyRHQZdkr+cjh1ovlrC SRTL1kh26JXJ5BkxIinsxjYSYpQzEIKB0B+0rzAsGzfTPDa5ffs6INMr0PfezQW0eKzr BxxqMFXqsd4j6oI4VnG4TFZY0DU1FvxPjiYUzMAlizG4S59rXI6ccuEnhAJ+1dQeqTNT 9cQ3pgkxrlM8MvmWgnazBhvTRFtOdNYRDDmRG6hrUbEjebl7zRB6gM0LgeZKCh4+LPxk 5D7azfSCHL7y1q3Gg4ew5OgZw/9paDpOmWaGiBYyx597xzf8rXCqP1mzTkmtnLvfwu+c hpFA== X-Gm-Message-State: AOAM532UEcLPViaKog0vPmG6Kr+M/oZ5XwmXEUh8jXFt9y15gbS34JJV wzYMiiMDYIXaDF2UEpAJxpVFGiW4ROqK1DPxesWee7PfWxrYYQ== X-Google-Smtp-Source: ABdhPJyQO1Ypmss7F9JtBJvfyJ2T6gA/zHz3aGDcxE2LvRHMlB0JEESu8sJ8bZ99S47xs/37ijAQqTB+ACr333KyuJw= X-Received: by 2002:a9d:77d1:: with SMTP id w17mr4791136otl.329.1636623388618; Thu, 11 Nov 2021 01:36:28 -0800 (PST) MIME-Version: 1.0 References: <20211110202448.4054153-1-valentin.schneider@arm.com> <20211110202448.4054153-3-valentin.schneider@arm.com> <803a905890530ea1b86db6ac45bd1fd940cf0ac3.camel@gmx.de> In-Reply-To: From: Marco Elver Date: Thu, 11 Nov 2021 10:36:17 +0100 Message-ID: Subject: Re: [PATCH v2 2/5] preempt/dynamic: Introduce preempt mode accessors To: Mike Galbraith Cc: Valentin Schneider , linux-kernel@vger.kernel.org, kasan-dev@googlegroups.com, linuxppc-dev@lists.ozlabs.org, linux-kbuild@vger.kernel.org, Peter Zijlstra , Ingo Molnar , Frederic Weisbecker , Dmitry Vyukov , Michael Ellerman , Benjamin Herrenschmidt , Paul Mackerras , Steven Rostedt , Masahiro Yamada , Michal Marek , Nick Desaulniers Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 11 Nov 2021 at 04:47, Mike Galbraith wrote: > > On Thu, 2021-11-11 at 04:35 +0100, Mike Galbraith wrote: > > On Thu, 2021-11-11 at 04:16 +0100, Mike Galbraith wrote: > > > On Wed, 2021-11-10 at 20:24 +0000, Valentin Schneider wrote: > > > > > > > > diff --git a/include/linux/sched.h b/include/linux/sched.h > > > > index 5f8db54226af..0640d5622496 100644 > > > > --- a/include/linux/sched.h > > > > +++ b/include/linux/sched.h > > > > @@ -2073,6 +2073,22 @@ static inline void cond_resched_rcu(void) > > > > #endif > > > > } > > > > > > > > +#ifdef CONFIG_PREEMPT_DYNAMIC > > > > + > > > > +extern bool is_preempt_none(void); > > > > +extern bool is_preempt_voluntary(void); > > > > +extern bool is_preempt_full(void); > > > > + > > > > +#else > > > > + > > > > +#define is_preempt_none() IS_ENABLED(CONFIG_PREEMPT_NONE) > > > > +#define is_preempt_voluntary() > > > > IS_ENABLED(CONFIG_PREEMPT_VOLUNTARY) > > > > +#define is_preempt_full() IS_ENABLED(CONFIG_PREEMPT) > > > > > > I think that should be IS_ENABLED(CONFIG_PREEMPTION), see > > > c1a280b68d4e. > > > > > > Noticed while applying the series to an RT tree, where tglx > > > has done that replacement to the powerpc spot your next patch > > > diddles. > > > > Damn, then comes patch 5 properly differentiating PREEMPT/PREEMPT_RT. > > So I suppose the powerpc spot should remain CONFIG_PREEMPT and become > CONFIG_PREEMPTION when the RT change gets merged, because that spot is > about full preemptibility, not a distinct preemption model. > > That's rather annoying :-/ I guess the question is if is_preempt_full() should be true also if is_preempt_rt() is true? Not sure all cases are happy with that, e.g. the kernel/trace/trace.c case, which wants to print the precise preemption level. To avoid confusion, I'd introduce another helper that says true if the preemption level is "at least full", currently that'd be "full or rt". Something like is_preempt_full_or_rt() (but might as well write "is_preempt_full() || is_preempt_rt()"), or is_preemption() (to match that Kconfig variable, although it's slightly confusing). The implementation of that helper can just be a static inline function returning "is_preempt_full() || is_preempt_rt()". Would that help?