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 5C8F5EB64D7 for ; Mon, 26 Jun 2023 19:53:05 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229481AbjFZTxE (ORCPT ); Mon, 26 Jun 2023 15:53:04 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:49318 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229454AbjFZTxC (ORCPT ); Mon, 26 Jun 2023 15:53:02 -0400 Received: from mga12.intel.com (mga12.intel.com [192.55.52.136]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 01F3AE7E; Mon, 26 Jun 2023 12:53:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1687809182; x=1719345182; h=message-id:subject:from:to:cc:date:in-reply-to: references:content-transfer-encoding:mime-version; bh=6SK8NB2LsBYbp7+J0GVDHHXUhFuGKobVNw10WdKFO2s=; b=YS61IW9SxFTXZYlrRSv7ZP452Gzb0cBZysYOYOEi9XnYglOlMdVI4oUy ZDhPLtnx/uTrstRjAIh8i9A+xqQ7DO8wOffFDFXBBAIJTmU+5w1Z1bo6y 77zCoptY3h4GFqqGYGeS69ReYJQfMwXcFA9xEiyHmJ3o2vgS/cSPLhwGj FDzT+GD+RS+UWpM0CPEdHvEEEIsloeJwnse+v6NrboFZohxIiqN7R2hoZ S4YEUqAcN5OYuiHHIq2o46fo8hN+3yPetdTlJdizzuaFXxdSuYCVZP8ql oR5/2s8lkzbIIjAr8NcGqrv3gpkg7NNRW6iBV8UseBoaRLwRfonkixVWO A==; X-IronPort-AV: E=McAfee;i="6600,9927,10753"; a="340959275" X-IronPort-AV: E=Sophos;i="6.01,160,1684825200"; d="scan'208";a="340959275" Received: from fmsmga008.fm.intel.com ([10.253.24.58]) by fmsmga106.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 26 Jun 2023 12:53:01 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10753"; a="781576168" X-IronPort-AV: E=Sophos;i="6.01,160,1684825200"; d="scan'208";a="781576168" Received: from jingyan2-mobl.amr.corp.intel.com (HELO [10.209.115.106]) ([10.209.115.106]) by fmsmga008-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 26 Jun 2023 12:53:00 -0700 Message-ID: Subject: Re: [PATCH v4 06/24] sched/fair: Collect load-balancing stats for IPC classes From: Tim Chen To: Ricardo Neri , Ionela Voinescu Cc: "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 Date: Mon, 26 Jun 2023 12:52:59 -0700 In-Reply-To: <20230624000121.GA32639@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> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.44.4 (3.44.4-2.fc36) MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: linux-pm@vger.kernel.org > >=20 > > nit: the comment is unnecessary, and a bit misleading, IMO. > >=20 > > 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. >=20 > 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. May need a special value like -EINVAL and make the score a "long" to mark such case. Tim