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 mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 8F06CC433F5 for ; Mon, 8 Nov 2021 08:49:54 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 2FB786125F for ; Mon, 8 Nov 2021 08:49:54 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 2FB786125F Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id CEDD36B0072; Mon, 8 Nov 2021 03:49:53 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id C9DF46B0073; Mon, 8 Nov 2021 03:49:53 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B8DD86B0074; Mon, 8 Nov 2021 03:49:53 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0080.hostedemail.com [216.40.44.80]) by kanga.kvack.org (Postfix) with ESMTP id ACFC86B0072 for ; Mon, 8 Nov 2021 03:49:53 -0500 (EST) Received: from smtpin21.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 73ED17594B for ; Mon, 8 Nov 2021 08:49:53 +0000 (UTC) X-FDA: 78785140266.21.2C69A08 Received: from mail-lf1-f42.google.com (mail-lf1-f42.google.com [209.85.167.42]) by imf27.hostedemail.com (Postfix) with ESMTP id 1CE2970009F4 for ; Mon, 8 Nov 2021 08:49:53 +0000 (UTC) Received: by mail-lf1-f42.google.com with SMTP id f3so34350040lfu.12 for ; Mon, 08 Nov 2021 00:49:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=NC6D/WS8Gp+h4dIR9Catgw+sLa+kzIQU0LzOCWmVhrM=; b=LujYT2JCFGjdzk+2fC32ggQUDjKXizNOHdnxDLypoRVtzT8GLM6W8KkS6bBtKiaJ3s CZ8D7mKp2MBmyNj4YkpNemsaT57xYF1ax7w/8RZ3y6NmY259gAE3PMY66Lmpu94VBpry m/pKTKHdZU/F9HF/1y8PFQzkNmrj2wIXSBqI3GmXgB7xhzSGeKw0PAGPeJUunedLQikp 7rT4teXIU1RNvZ3jaEi1bH8c1sV0z5TJTlISfXNli/w+p+PQXhY4sare/g1TaS+B3C4j 44Y6+koNk1hbKRG/tz3XkfcZTPuqeKHJx5eKC2rklzBZ2CjfsCUyhaGOvKf4VeAxy8/q Lxig== 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=NC6D/WS8Gp+h4dIR9Catgw+sLa+kzIQU0LzOCWmVhrM=; b=vQFF31eNNNF1hL7Xhwi9vSQjTUSmeygTBTnLLGpGW3mmSZKc6WEhHMnllevrhf/cAG n+VYr/t3WkbRQKOYbBkWeZ2my0Zdn+bc2PO/h39dVahU/jzCJ67OsCtHO+wnG5sl04Jc 8hRhyM9fjYIUaN99ER4PNCsL+g+Eq8sW8UiL12wcbgtA8wYoTXcSXSEAMT5Zk981kE0e AWutdtRkAAHL/FmdlN9TdwyWHHDeXkpL6W6sj+SaiHWpdSmLtD39A3ZnMr632BB4Pj2B G/yxmZ362jELe8rHK3mrxaHEDL2Ux1nTiI/Ij6zZRM0gBX/MoTATygRYY6wIhB9qaJ0Y IDtw== X-Gm-Message-State: AOAM5335O6oYCG7WcA6HAwK4m4dj/KikCQr/do0sJwoNsILy7fxogJqo jjcby8CVe+tZ8nE/C4hXqDM8W798vzQHKuaGFMA= X-Google-Smtp-Source: ABdhPJwF3MCEgKFj4vvWPPbdNitPH62GPP/UPjjYD5+dZE6phEdbsCi7+BY69kIc8vwarxzNSoJq4rm3fdNHb27Kou8= X-Received: by 2002:a05:6512:2346:: with SMTP id p6mr39368133lfu.503.1636361391539; Mon, 08 Nov 2021 00:49:51 -0800 (PST) MIME-Version: 1.0 References: <1634278612-17055-1-git-send-email-huangzhaoyang@gmail.com> <78b3f72b-3fe7-f2e0-0e6b-32f28b8ce777@arm.com> <85c81ab7-49ed-aba5-6221-ea6a8f37f8ad@arm.com> In-Reply-To: <85c81ab7-49ed-aba5-6221-ea6a8f37f8ad@arm.com> From: Xuewen Yan Date: Mon, 8 Nov 2021 16:49:39 +0800 Message-ID: Subject: Re: [Resend PATCH] psi : calc cfs task memstall time more precisely To: Dietmar Eggemann Cc: Zhaoyang Huang , Johannes Weiner , Andrew Morton , Michal Hocko , Vladimir Davydov , Zhaoyang Huang , "open list:MEMORY MANAGEMENT" , LKML , Peter Zijlstra , Vincent Guittot , xuewen.yan@unisoc.com, Ke Wang Content-Type: text/plain; charset="UTF-8" Authentication-Results: imf27.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=LujYT2JC; spf=pass (imf27.hostedemail.com: domain of xuewen.yan94@gmail.com designates 209.85.167.42 as permitted sender) smtp.mailfrom=xuewen.yan94@gmail.com; dmarc=pass (policy=none) header.from=gmail.com X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 1CE2970009F4 X-Stat-Signature: ofgjemie1udjn49rek9zdpusuxt34cbz X-HE-Tag: 1636361393-472685 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: Hi Dietmar On Sat, Nov 6, 2021 at 1:20 AM Dietmar Eggemann wrote: > > On 05/11/2021 06:58, Zhaoyang Huang wrote: > >> I don't understand the EAS (probably asymmetric CPU capacity is meant > >> here) angle of the story. Pressure on CPU capacity which is usable for > >> CFS happens on SMP as well? > > Mentioning EAS here mainly about RT tasks preempting small CFS tasks > > (big CFS tasks could be scheduled to big core), which would introduce > > more proportion of preempted time within PSI_MEM_STALL than SMP does. > > What's your CPU layout? Do you have the little before the big CPUs? Like > Hikey 960? > > root@linaro-developer:~# cat /sys/devices/system/cpu/cpu*/cpu_capacity > 462 > 462 > 462 > 462 > 1024 > 1024 > 1024 > 1024 > > And I guess rt class prefers lower CPU numbers hence you see this? > our CPU layout is: xuewen.yan:/ # cat /sys/devices/system/cpu/cpu*/cpu_capacity 544 544 544 544 544 544 1024 1024 And in our platform, we use the kernel in mobile phones with Android. And we prefer power, so we prefer the RT class to run on little cores. > >> > >> This will let the idle task (swapper) pass. Is this indented? Or do you > >> want to only let CFS tasks (including SCHED_IDLE) pass? > > idle tasks will NOT call psi_memstall_xxx. We just want CFS tasks to > > scale the STALL time. > > Not sure I get this. > > __schedule() -> psi_sched_switch() -> psi_task_change() -> > psi_group_change() -> record_times() -> psi_memtime_fixup() > > is something else than calling psi_memstall_enter() or _leave()? > > IMHO, at least record_times() can be called with current equal > swapper/X. Or is it that PSI_MEM_SOME is never set for the idle task in > this callstack? I don't know the PSI internals. > > >> > >> if (current->sched_class != &fair_sched_class) > >> return growth_fixed; > >> > >>>>>> + > >>>>>> + if (current->in_memstall) > >>>>>> + growth_fixed = div64_ul((1024 - rq->avg_rt.util_avg - rq->avg_dl.util_avg > >>>>>> + - rq->avg_irq.util_avg + 1) * growth, 1024); > >>>>>> + > >> > >> We do this slightly different in scale_rt_capacity() [fair.c]: > >> > >> max = arch_scale_cpu_capacity(cpu_of(rq) /* instead of 1024 to support > >> asymmetric CPU capacity */ > > Is it possible that the SUM of rqs' util_avg large than > > arch_scale_cpu_capacity because of task migration things? > > I assume you meant if the rq (cpu_rq(CPUx)) util_avg sum (CFS, RT, DL, > IRQ and thermal part) can be larger than arch_scale_cpu_capacity(CPUx)? > > Yes it can. > > Have a lock at > > effective_cpu_util(..., max, ...) { > > if (foo >= max) > return max; > > } > > Even the CFS part (cpu_rq(CPUx)->cfs.avg.util_avg) can be larger than > the original cpu capacity (rq->cpu_capacity_orig). > > Have a look at cpu_util(). capacity_orig_of(CPUx) and > arch_scale_cpu_capacity(CPUx) both returning rq->cpu_capacity_orig. > Well, your means is we should not use the 1024 and should use the original cpu capacity? And maybe use the "sched_cpu_util()" is a good choice just like this: + if (current->in_memstall) + growth_fixed = div64_ul(cpu_util_cfs(rq) * growth, sched_cpu_util(rq->cpu, capacity_orig_of(rq->cpu))); Thanks! BR xuewen