Received: by 2002:a05:6602:18e:0:0:0:0 with SMTP id m14csp433155ioo; Sat, 21 May 2022 03:38:08 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzgkAG2OHtmT/4CIIjo4HaqYzYJLDhvK9Bh4k4rP/NzTlaXgMJ1SjKYf01SPgMvjxMTElKc X-Received: by 2002:a17:907:628a:b0:6fe:526c:ebc with SMTP id nd10-20020a170907628a00b006fe526c0ebcmr11997981ejc.531.1653129488224; Sat, 21 May 2022 03:38:08 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1653129488; cv=none; d=google.com; s=arc-20160816; b=UycL6JRPTidUdsVBvBj9e5itBrdY96I6zY/cl9gYWBMokaXz2JHbmMgrKfQogEE58z UBWc2YVhDPWa8EVuxHoaf42ZbjhjvDOgWqEDmDnyXH6V5loTkNFj1A6iGaZHcVxQd55f mzoZR3Ahm4O839S+gzxBQ98Y4Hllv/LoDnRbNzeR0qSxJQK32xhMkNZsn4g11XZ2X/Jt AuFz2osZL+Pfd2x4WTECI4D7ATxnD9+5TwG5kmHICB2vfn0yt1zjuXi/erbOrGpYsKaf laC/jR3TkEA5EPRoHK8YXQBqJrf+JPB3HkiEFD8EtTBE4zvdiLfWCJrV4XTCWcLnMUep 5R6Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=r1fS3IXIw/s+vzbyRwSGih92mZvaWIhj50yzhP08HyE=; b=PintNjMGOG2tAkMJ435nhvpqJOPvc3gw34H9T285P3htEGRoH1JRjCNBp1Pma1XLPF h1RCAdY5W6C6PIDAGK8YWBwsH/6DWr9/toOQnb2LyCQr2TkMO9Ag3HLo2LLxus1SuZEc l5Rj/0uFdJ/H9LyRDlfSu5WoWdMkgjsb+pkq3/p4FlXfDtasF0i5cuGjidxtHOcT1y6f m0/VSc0yxpYZOQYb9qq+i3aXrO+YLPhnI8zjOEIMQrkOlcfPgU6HvYN7m4Wmbu8yaJdZ CcZDusaaOCZDLDC+iSkzF9DPzUKNzdNEpLj788MLyU35FjD0IxvaRUgxsRg5OjMgrhOT np+w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=eiVwXC0j; 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=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id sc12-20020a1709078a0c00b006fec3d39909si580810ejc.572.2022.05.21.03.37.42; Sat, 21 May 2022 03:38:08 -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=@google.com header.s=20210112 header.b=eiVwXC0j; 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=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1353988AbiETXJy (ORCPT + 99 others); Fri, 20 May 2022 19:09:54 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:60082 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1347085AbiETXJs (ORCPT ); Fri, 20 May 2022 19:09:48 -0400 Received: from mail-yb1-xb2a.google.com (mail-yb1-xb2a.google.com [IPv6:2607:f8b0:4864:20::b2a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C771E1912CC for ; Fri, 20 May 2022 16:09:45 -0700 (PDT) Received: by mail-yb1-xb2a.google.com with SMTP id d137so16415245ybc.13 for ; Fri, 20 May 2022 16:09:45 -0700 (PDT) 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=r1fS3IXIw/s+vzbyRwSGih92mZvaWIhj50yzhP08HyE=; b=eiVwXC0jIMcRJTf0ETo7duPL65FRe2ML4mHwbAFMyPHAT97FZdTn0OUukopDTLklTQ D6aVh2Ox1qFMAorJaL82OLTnTzqqu7dgw4M0PxB3s3e/K1KQmDJd+vrx3sZeBweXeoTE /ARoKm3VLXPGEiXqjNU33aMYqulHt5V/zvM2+3gHmxIVNEQ1oNt35l3vgsQJEmneuvql VEUOjvyJTSyoUllwvjSZsc3OHReV73tYP7XkaRjJn6rAhH4mNusEekmpZIQfuTW+qGdX WroCkVOTZcRVwC37ute8cckL/U5q4wunJSFV3xrOgpA9phs4OFwlyYA10C2UPf8wcnsF 5RDw== 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=r1fS3IXIw/s+vzbyRwSGih92mZvaWIhj50yzhP08HyE=; b=YCn7tpyTgt/GfNokH0T3GMa4D8nlhnuqslNGsNL9Q1vRbXUGXuQTBLkXXZzNxvYARi 1KNGlRyyakTabO2EVZfUNUyl5QX9neuP8xzXP+tjJjAmVy80nv0mmBkzcLGcWgItKhnu abXHdGFW5qVW7d5Y2aEaxz/8/+uj2N1xM8LugzJjw/k5IW8Wi2/xuiMcX92MiYJIUUMN cuOq5+xJBbLTWPjb6FU4cEv47iM2orioPVot3FO372LEEzGJzlI7OgzIlFVQe36PR8ev 2qdqZENATcAifcUtHB5K1butv1FgAPoFDpOhCJkNn+1JaTDVO5OQ1xB1n5HwrVXZ22M+ VS2A== X-Gm-Message-State: AOAM533V2eh+5oAuPYSknMu1VmbBeRQAzIKRIIfoJtLnpwzKS2sJF7z4 YlfIIEmMimipVrYJc7AohSJTgfGFkOTwvT+TmzbHpA== X-Received: by 2002:a25:2c55:0:b0:64d:f682:db36 with SMTP id s82-20020a252c55000000b0064df682db36mr12248097ybs.352.1653088184749; Fri, 20 May 2022 16:09:44 -0700 (PDT) MIME-Version: 1.0 References: <20220513005427.2507335-1-joshdon@google.com> In-Reply-To: From: Josh Don Date: Fri, 20 May 2022 16:09:33 -0700 Message-ID: Subject: Re: [PATCH] sched/core: add forced idle accounting for cgroups To: Tejun Heo Cc: Ingo Molnar , Peter Zijlstra , Juri Lelli , Vincent Guittot , Dietmar Eggemann , Steven Rostedt , Ben Segall , Mel Gorman , Daniel Bristot de Oliveira , Valentin Schneider , linux-kernel , Cruz Zhao Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-17.6 required=5.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF, ENV_AND_HDR_SPF_MATCH,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS, T_SCC_BODY_TEXT_LINE,USER_IN_DEF_DKIM_WL,USER_IN_DEF_SPF_WL 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 Fri, May 20, 2022 at 11:43 AM Tejun Heo wrote: > > Hello, > > Sorry about late reply and thanks for the ping. I missed this one. > > On Fri, May 13, 2022 at 12:23:16PM -0700, Josh Don wrote: > > Yea, that's right, this doesn't require the cpu controller to be > > enabled. Are you suggesting to add a new field to cgroup_base_stat? > > Yes, that's what I meant. I think it'd fit there better. Sounds good, I'll send a second version of the patch with that change. > > One other weird artifact of collecting forceidle time is that a cpu > > may account it on behalf of its hyperthread sibling. Currently, the > > core rstat code always accounts to the current cpu's percpu rstat > > field. I can add an accounting function to support writes to a > > different cpu's field, in order to make sure that the per-cpu totals > > are correct (the forceidle accounting code holds rq->__lock, which > > protects all HT siblings of a core). percpu totals aren't currently > > exported in cgroup v2, but this is useful information that we'll > > consume, so it would be nice to keep it accurate. > > Sure, as long as it doesn't incur overhead when not used. The extra complexity actually doesn't seem to be required. Per-core totals will be accurate, which is the important part. Thanks, Josh