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 6EE6FEB64DD for ; Thu, 6 Jul 2023 23:38:22 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231889AbjGFXiV (ORCPT ); Thu, 6 Jul 2023 19:38:21 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43996 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229522AbjGFXiT (ORCPT ); Thu, 6 Jul 2023 19:38:19 -0400 Received: from mga18.intel.com (mga18.intel.com [134.134.136.126]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 511D81BE9; Thu, 6 Jul 2023 16:38:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1688686698; x=1720222698; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=0JKvud1PQdDP/vY9wglSJ4Q5ihblqLm8EVHVndBkp7Y=; b=d1jzLILO73L2R7BUXqAgjMhI0WKZe4bZ11FS102lu4ZwtmcYwTAEZ0wu uJ+7x54sesy4Wv+wTcNONGg5n8j9rvdrotcZBURS934ehcMzfR67TDLsS kPHmAjRza8/MKeSDELl3Opjy5nw+qjzVwCeXeV0aCJejOHRbuEac71dr4 1nYgMHX/DP4SbMTNDsNG/wqOJLKFPx4DF6faMUrIqmCT4hI37BfGdMJsM RfUNP+7Pi4tOoSqMpQHOHL3LUb1KLYz1VgR/mdAgvIn9pdEX7s0u94cqx yHSIoCaqV/hEqZfI+tnXiBq61fHR6wKVGTJ0x7QFQkfg7zjUaeCADDN8d w==; X-IronPort-AV: E=McAfee;i="6600,9927,10763"; a="348550714" X-IronPort-AV: E=Sophos;i="6.01,187,1684825200"; d="scan'208";a="348550714" Received: from orsmga001.jf.intel.com ([10.7.209.18]) by orsmga106.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 06 Jul 2023 16:38:16 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10763"; a="754927658" X-IronPort-AV: E=Sophos;i="6.01,187,1684825200"; d="scan'208";a="754927658" Received: from ranerica-svr.sc.intel.com ([172.25.110.23]) by orsmga001.jf.intel.com with ESMTP; 06 Jul 2023 16:38:15 -0700 Date: Thu, 6 Jul 2023 16:40:59 -0700 From: Ricardo Neri To: Tim Chen Cc: Ionela Voinescu , "Peter Zijlstra (Intel)" , 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 , Valentin Schneider , Lukasz Luba , Zhao Liu , "Yuan, Perry" , x86@kernel.org, "Joel Fernandes (Google)" , linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org, "Tim C . Chen" , Zhao Liu Subject: Re: [PATCH v4 06/24] sched/fair: Collect load-balancing stats for IPC classes Message-ID: <20230706234058.GC12259@ranerica-svr.sc.intel.com> References: <20230613042422.5344-1-ricardo.neri-calderon@linux.intel.com> <20230613042422.5344-7-ricardo.neri-calderon@linux.intel.com> <20230624000121.GA32639@ranerica-svr.sc.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 Mon, Jun 26, 2023 at 12:52:59PM -0700, Tim Chen wrote: > > > > > > > nit: the comment is unnecessary, and a bit misleading, IMO. > > > > > > The comment says "This group will not be selected." but the only way to > > > guarantee that here is to reset the sum_score to 0 when you find an > > > invalid score, which I don't believe is your intention. > > > > You raise an interesting point. We will call this function for each rq > > in the sched group. Thus, if we encounter an error, the scores would be > > incomplete. Therefore, I think that the scores should be discarded and > > reset to 0 so that they are not used, IMO. > > Since we still have other rqs to loop through, reset to 0 here does > not guarantee that it will stay that way at the end of the loop when > the sum could still be added to. That is true, to discard the would need an indication that we should not keep iterating on the runqueues of this group. > May need a special value like -EINVAL > and make the score a "long" to mark such case. IIUC, unsigned longs allow to handle negative errors if you use IS_ERR_VALUE(); but yes, it looks odd.