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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id E5392C433F5 for ; Sat, 1 Oct 2022 20:26:25 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229680AbiJAU0Y (ORCPT ); Sat, 1 Oct 2022 16:26:24 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:36092 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229558AbiJAU0W (ORCPT ); Sat, 1 Oct 2022 16:26:22 -0400 Received: from mga06.intel.com (mga06b.intel.com [134.134.136.31]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 1CD0A41995 for ; Sat, 1 Oct 2022 13:26:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1664655980; x=1696191980; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=1mEVKTYWv5eS2CDrFkoAREIRnT6Os4xXgAOTnYNfDFI=; b=gKlIyp7yhm+ARGuFAnyaPYAhOVNI0MiY9sjPzU2hLv0KM6bB0+cXch2h 9S0XdmwJNYCEKqFtrTeE3k8JjX2nCo7uYzBrEgvrrcrgjjAWoGIXyc7nW JeChIr6hFY9z0RCD7LrqaXYE8WobZUkymfLbVCIH9LRfwgVtaBV2F5ay4 AWSdRls2VR95YcFgmVKAnTbXCfvsbnnTMDUZzJHNmBfN7/Ub0xIzMJcSA 03C+LdtZTJ/jPWEFsv3CeYooIy5JFv9k0NPYtAltUn6ZhKrcY/LPiQXrV g1LDAXnPaqvjNW3ldhNRt2fHgj3H65trTr48zVyneR3Dhjqj3wgt9hik1 g==; X-IronPort-AV: E=McAfee;i="6500,9779,10487"; a="364259106" X-IronPort-AV: E=Sophos;i="5.93,361,1654585200"; d="scan'208";a="364259106" Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by orsmga104.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 01 Oct 2022 13:26:19 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6500,9779,10487"; a="727286257" X-IronPort-AV: E=Sophos;i="5.93,361,1654585200"; d="scan'208";a="727286257" Received: from ranerica-svr.sc.intel.com ([172.25.110.23]) by fmsmga002.fm.intel.com with ESMTP; 01 Oct 2022 13:26:19 -0700 Date: Sat, 1 Oct 2022 13:32:41 -0700 From: Ricardo Neri To: Peter Zijlstra Cc: Joel Fernandes , Juri Lelli , Vincent Guittot , Ricardo Neri , "Ravi V. Shankar" , Ben Segall , Daniel Bristot de Oliveira , Dietmar Eggemann , Len Brown , Mel Gorman , "Rafael J. Wysocki" , Srinivas Pandruvada , Steven Rostedt , Tim Chen , Valentin Schneider , x86@kernel.org, linux-kernel@vger.kernel.org, "Tim C . Chen" Subject: Re: [RFC PATCH 03/23] sched/core: Initialize the class of a new task Message-ID: <20221001203241.GA14536@ranerica-svr.sc.intel.com> References: <20220909231205.14009-1-ricardo.neri-calderon@linux.intel.com> <20220909231205.14009-4-ricardo.neri-calderon@linux.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Sep 27, 2022 at 03:04:39PM +0200, Peter Zijlstra wrote: > On Mon, Sep 26, 2022 at 02:57:29PM +0000, Joel Fernandes wrote: > > > > +#ifdef CONFIG_SCHED_TASK_CLASSES > > > + p->class = TASK_CLASS_UNCLASSIFIED; > > > +#endif > > > > I find the term 'class' very broad and unclear what kind of class (without > > further reading). So I am worried about how this generic term usage plays > > with Linux source code in the long-term (like what if someone else comes up > > with a usage of term 'class' that is unrelated to IPC.) > > However much I like making a pain for people using C++ to compile the > kernel, I do think ipcc might be better here > (instructions_per_cycle_class for those of the novel per identifier > school of thought). Sure, I will use ippc > > > To that end, I was wondering if it could be renamed to p->ipc_class, and > > CONFIG_SCHED_TASK_IPC_CLASSES, or something. > > Can we *please* shorten those thing instead of writing a novel? > CONFIG_SCHED_IPC_CLASS works just as well, no? Or TASK_IPC, whatever. ... and avoid the novel-style identifiers :) . Thanks and BR, Ricardo