Received: by 2002:a05:6358:11c7:b0:104:8066:f915 with SMTP id i7csp4842543rwl; Mon, 3 Apr 2023 10:18:59 -0700 (PDT) X-Google-Smtp-Source: AKy350ZmqPeOelLPd8xmVNl/aXFt3VoJQaaiLLzUqNTiu5yxJm8ooph33oITBqoRDXYsvpuB63ai X-Received: by 2002:aa7:d797:0:b0:4fb:6796:14c0 with SMTP id s23-20020aa7d797000000b004fb679614c0mr36762033edq.22.1680542339623; Mon, 03 Apr 2023 10:18:59 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1680542339; cv=none; d=google.com; s=arc-20160816; b=kop0zgawj1hOvqW+K9Ot1n7W23u5GSIFqXXA9ALmMiVvK6MIPnYicmdcOUQscjwJMm Y4O0K+cggj7ePuTkrdbgZNCpCMwLHbIRReVLw+3miB9fWuf6S02bu2WTRiSArnAKPdKJ Pz2lMKxz/47ZlchA1s1KR5Bfw2hBFACCnjxZVBF9XVDpioVxk2z+XujFhDhGMNHlHTI0 SxXBoWv25RvWL7ivPjxpDyclWlfQ+ylmdVrqgbdxFnFBg/GNW3tc8JK3E06tk6B0KwOT LuXduNS0mWzHYqcifKcRTRcv9T2oDXvf8d44X4O9beO4N09ds3CNiH/HVABNH8rVqlla NNmA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to:from :references:cc:to:content-language:subject:user-agent:mime-version :date:message-id; bh=kip7sLF0O40TbExHI3FHyaTpH0Ziqm+nxw01M/6c0N4=; b=WXhRmNUh5yOo7xE94y6HKxVGWKsdcTtO0hEn1xGB6TvruVNpz0JCv/ePPlk5Uflb+W qhv+5x/swOjkzqBP7eoWhUezGDfC8RLI7/1wpq3JBXBUMXYSisLVQWGacy8apHnuMnXO 16rjVseAkQv0t1t9hUIMyQAMk27g4WThWHy07/mZclOU0goKAmv4AP0DYvZBf84PUwz3 MbpyTjmsf1nZP0+S0SVem2EkjRHRfyyeT4N8UlMl5ObC8BgQA/O3VyWh0vBXUCCS8vyF YQX/GtWeLHsU9ywW0vpXQTMikRiCOGtBw8Q/8fjE4nuGJnbn0oukg/THBzAJ0S52tT18 VSIQ== ARC-Authentication-Results: i=1; mx.google.com; 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=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id v7-20020aa7d647000000b004c0abff5545si3890110edr.614.2023.04.03.10.18.33; Mon, 03 Apr 2023 10:18:59 -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; 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=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232750AbjDCQrK (ORCPT + 99 others); Mon, 3 Apr 2023 12:47:10 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:55930 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231899AbjDCQrI (ORCPT ); Mon, 3 Apr 2023 12:47:08 -0400 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 0F945171E; Mon, 3 Apr 2023 09:47:06 -0700 (PDT) Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 08CFBFEC; Mon, 3 Apr 2023 09:47:51 -0700 (PDT) Received: from [10.57.20.195] (unknown [10.57.20.195]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id E1DEC3F6C4; Mon, 3 Apr 2023 09:47:03 -0700 (PDT) Message-ID: Date: Mon, 3 Apr 2023 17:47:02 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.9.0 Subject: Re: [PATCH 1/3] sched/tp: Add new tracepoint to track uclamp set from user-space Content-Language: en-US To: Qais Yousef Cc: linux-kernel@vger.kernel.org, linux-trace-kernel@vger.kernel.org, rostedt@goodmis.org, mhiramat@kernel.org, mingo@redhat.com, peterz@infradead.org, juri.lelli@redhat.com, vincent.guittot@linaro.org, dietmar.eggemann@arm.com, bsegall@google.com, mgorman@suse.de, bristot@redhat.com, vschneid@redhat.com, delyank@fb.com, qyousef@google.com References: <20230322151843.14390-1-lukasz.luba@arm.com> <20230322151843.14390-2-lukasz.luba@arm.com> <20230403134606.amdxfmr5fb544xnv@airbuntu> From: Lukasz Luba In-Reply-To: <20230403134606.amdxfmr5fb544xnv@airbuntu> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-3.6 required=5.0 tests=NICE_REPLY_A, RCVD_IN_DNSWL_MED,SPF_HELO_NONE,SPF_NONE autolearn=unavailable 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 Hi Qais, On 4/3/23 14:46, Qais Yousef wrote: > Hi Lukasz! > > On 03/22/23 15:18, Lukasz Luba wrote: >> The user-space can set uclamp value for a given task. It impacts task >> placement decisions made by the scheduler. This is very useful information >> and helps to understand the system behavior or track improvements in >> middleware and applications which start using uclamp mechanisms and report >> better performance in tests. > > We do have uclamp trace events in sched_tp, why are they not sufficient? > > https://github.com/qais-yousef/sched_tp/blob/main/sched_events.h#L233 > > Do you really want to know the exact time the value has changed? Yes, that's why these new are triggered instantly after userspace wanted to set the new uclamp values. We are going to have a few different uclamp implementations: one in mainline and X in Android vendor kernels. The goal is to have only one... We will have to experiment to find the behavior of those algorithms and understand the differences. Since uclamp is part of this 'control-chain' of CPU frequency and also task placement - it would be really tricky to figure our everything. The analysis on traces are crucial for this. > > Would it make sense to introduce a generic sched_setscheduler tracepoint > instead? Although this might not be necessary as I think we can use > register_kprobe() to register a callback and create a new event without any > additional tracepoint. sched_setscheduler() is not inlined so should be easy to > hook into and create events, no? This looks very complex and we already have our LISA tool with the module to change the tracepoints into trace events and build them. I wanted to be aligned with that design, which might look a bit old-fashion but is simple IMO. The 'sched_setscheduler tracepoint' might be a too big for this purpose. Thanks for the comments :) Lukasz > > > Thanks > > -- > Qais Yousef > >> >> Signed-off-by: Lukasz Luba >> --- >> include/trace/events/sched.h | 4 ++++ >> kernel/sched/core.c | 5 +++++ >> 2 files changed, 9 insertions(+) >> >> diff --git a/include/trace/events/sched.h b/include/trace/events/sched.h >> index fbb99a61f714..dbfb30809f15 100644 >> --- a/include/trace/events/sched.h >> +++ b/include/trace/events/sched.h >> @@ -735,6 +735,10 @@ DECLARE_TRACE(sched_update_nr_running_tp, >> TP_PROTO(struct rq *rq, int change), >> TP_ARGS(rq, change)); >> >> +DECLARE_TRACE(uclamp_update_tsk_tp, >> + TP_PROTO(struct task_struct *tsk, int uclamp_id, unsigned int value), >> + TP_ARGS(tsk, uclamp_id, value)); >> + >> #endif /* _TRACE_SCHED_H */ >> >> /* This part must be outside protection */ >> diff --git a/kernel/sched/core.c b/kernel/sched/core.c >> index 488655f2319f..882c92e3ccf0 100644 >> --- a/kernel/sched/core.c >> +++ b/kernel/sched/core.c >> @@ -110,6 +110,7 @@ EXPORT_TRACEPOINT_SYMBOL_GPL(sched_overutilized_tp); >> EXPORT_TRACEPOINT_SYMBOL_GPL(sched_util_est_cfs_tp); >> EXPORT_TRACEPOINT_SYMBOL_GPL(sched_util_est_se_tp); >> EXPORT_TRACEPOINT_SYMBOL_GPL(sched_update_nr_running_tp); >> +EXPORT_TRACEPOINT_SYMBOL_GPL(uclamp_update_tsk_tp); >> >> DEFINE_PER_CPU_SHARED_ALIGNED(struct rq, runqueues); >> >> @@ -1936,12 +1937,16 @@ static void __setscheduler_uclamp(struct task_struct *p, >> attr->sched_util_min != -1) { >> uclamp_se_set(&p->uclamp_req[UCLAMP_MIN], >> attr->sched_util_min, true); >> + trace_uclamp_update_tsk_tp(p, UCLAMP_MIN, >> + attr->sched_util_min); >> } >> >> if (attr->sched_flags & SCHED_FLAG_UTIL_CLAMP_MAX && >> attr->sched_util_max != -1) { >> uclamp_se_set(&p->uclamp_req[UCLAMP_MAX], >> attr->sched_util_max, true); >> + trace_uclamp_update_tsk_tp(p, UCLAMP_MAX, >> + attr->sched_util_max); >> } >> } >> >> -- >> 2.17.1 >>