Received: by 2002:a05:6359:c8b:b0:c7:702f:21d4 with SMTP id go11csp1059695rwb; Sat, 1 Oct 2022 14:20:03 -0700 (PDT) X-Google-Smtp-Source: AMsMyM5Pg8BZtL2XpGcZeWRvZYMWfTn1DQLYpUVKurVDLv83qprVKU+i+kYySN19+xYfU93EOGKw X-Received: by 2002:a17:902:ea11:b0:176:b283:9596 with SMTP id s17-20020a170902ea1100b00176b2839596mr14779118plg.69.1664659202761; Sat, 01 Oct 2022 14:20:02 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1664659202; cv=none; d=google.com; s=arc-20160816; b=oCgHuqGNqDds5Aa1cbMimu1LdWe9c8Gqpqi9P3LwPnLbCJrWRXFH5OpIbayC67tGsQ YAoVveUdmQNygLVeettnHcJ4PhzQbJMprfKrwYfvCTZS3eYopa9sK4hPSTO3Luy8vqqF JehWr8+OTJxfXaBgLtCASLE82IelDy+rm9z5fB88B9MAQ8JVAncYQaIk201wEahJGJEJ TBB0rBYSeLdl3Bckd7X1V1S4Ava+e1/QxMbFgOGhMelyPIJNnLnTIDlJH5kwQj7sb+pj ErwtKSWSRt1Lu5sVlGQoT56ktBjBY3ayEsPjtDPqKZ3w9BTcZa0prztQoT44O4CBLkBP fxEg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :dkim-signature; bh=RWnq7h3lAPA76kci3hD8wvbAGbwzMPDj9FOiJTlFceM=; b=GFdOkjuF+nMiao8uMa0EPpKcVuJbSFOmlbMl1Rb62EXpaxNgVbFEJlRdBFsdxhU7aY C124T2kCh8ks43kITKrndK/2I5mlipQ27XOdwnOkSeCb5R+Mvkq5PjJUho10SJpuoG9j LqKcENkxMJm68TidqA3xml4tRdcilQcxNDNxa5XSS39zcdVJo01rOIxmk/ub0zsO26G9 kBBLSO49/7TfPogt5R9HRMX9ei9/5nI1Uxe8MJ+FRwh3hbqRX9p2tobU3Ru2mVRw8Een zEcvC7AzLEWnlaaavIgmalKl25PJXt6ml/Nd37lyBbscH4W885E5LZ710CQiiRhn61hB DE+w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=gKlIyp7y; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id p4-20020a170902eac400b001785c39497esi6150494pld.410.2022.10.01.14.19.47; Sat, 01 Oct 2022 14:20:02 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=gKlIyp7y; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229678AbiJAU0X (ORCPT + 99 others); Sat, 1 Oct 2022 16:26:23 -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) X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_EF,RCVD_IN_DNSWL_MED,SPF_HELO_NONE, SPF_NONE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net 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