Received: by 2002:ac8:156:0:b0:3e0:cd10:60c8 with SMTP id f22csp1684313qtg; Tue, 21 Mar 2023 20:55:04 -0700 (PDT) X-Google-Smtp-Source: AK7set9+OrCUCe8FUEVnUMfUCyvoxblGw3bX5jXDut/kCH1TKFb79eHjvy85tQBbChywHYRuk+ly X-Received: by 2002:a17:907:20e1:b0:8b1:7ead:7d43 with SMTP id rh1-20020a17090720e100b008b17ead7d43mr5005399ejb.50.1679457304740; Tue, 21 Mar 2023 20:55:04 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1679457304; cv=none; d=google.com; s=arc-20160816; b=TQvdNvZOil1FtW50T2Our/mJw30f/qL+FwytvvytcQNn5J7BGqWs90vRjjhWZIh4HN ULn8b4KKOn6Y9FcEaVbe4P9/4Qw5lEwMi37++/ng6JFSUIc1qVb3wUeTQm3x8RdVqpgn 8FlqeqbYdUsj2QTlAjEpWBIZoePUfm0QFp8+sd8alj8NzL9tWVOQ0GV/+spVbb1oguFw mvDm9csaQoVV8i7TjRYGZcH3vP6ynhHcCKtSzYfGBx35pXcWVYM1FIPJ2CeACgMH+pmq eUoBpUWTirD7Xt6++kyU0IUx9erS+vB35roidWB/fFX1cQQA9TPtZSCbywEmllSZyLOZ ojNA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:cc:to:subject :message-id:date:from:in-reply-to:references:mime-version :dkim-signature; bh=V3jUG0oglxMHUcZ7R/TmWEumXbeO4lDHFIDhwNqEDys=; b=rfe4Uqzq+pOfl0fCArOyTIGn3Pugpo+fRJri7E4Q30EWHJZ5cQbf84mi/OgaP1fXYP s6jIMZ/MYXBzMQyI6PnrGlo4QH9GhQYyUTsMc1jg5Ly63r33p04nSqnHKQpZCaXNPvo8 Jwrenmr0t6b39J9cQCnX2cMppd0xQEZRpqGR9zxcS2iftc6SsplpPA+NstyciLyBnOAo SMshrCdxxvlX1YnffUuIm22OYKNaRTSCRdEUINHzh5gbmN7YUxazplIjadhE+iwJFPuu b8FTno5RcOd2cOzXXigmw1r1A7Jnn6oFa+fikDNfQ3W/bHEU1UwARLXY2MAHxAJBij8l /obA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=QgNe0dtN; 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 cw5-20020a170906478500b009338f516161si8658985ejc.707.2023.03.21.20.54.40; Tue, 21 Mar 2023 20:55:04 -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=QgNe0dtN; 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 S230056AbjCVDli (ORCPT + 99 others); Tue, 21 Mar 2023 23:41:38 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:52942 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229836AbjCVDlV (ORCPT ); Tue, 21 Mar 2023 23:41:21 -0400 Received: from mail-yb1-xb2e.google.com (mail-yb1-xb2e.google.com [IPv6:2607:f8b0:4864:20::b2e]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 5AA1E5AB55 for ; Tue, 21 Mar 2023 20:41:05 -0700 (PDT) Received: by mail-yb1-xb2e.google.com with SMTP id y5so19634014ybu.3 for ; Tue, 21 Mar 2023 20:41:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; t=1679456464; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=V3jUG0oglxMHUcZ7R/TmWEumXbeO4lDHFIDhwNqEDys=; b=QgNe0dtNidUBSmdsTDiK4Px2nDl8EPhFA/9VkGSCSMzzpyLMRXoJE4xlrw1NM2oQNK +mFspaVMAnaGws1YfyPgT+m/35w3PMt5+LtTPg7mCH8hIfHwolqG7yTpxPjT5mtWNLHw uJMXNRY5EBI5+OFtZAuIhCIPZJdhsLAeTjgK/8eiEQBpaqv0GvtshfA4JiILCp4EkPGC +cgHkdhMCNjmee+9DEJCQluc2GUGGyuMSJLa7GfDHy2pndNEkWG/xxX5Ki4dcu+opljo BPIg8gTp5kdel8ORqTP+jKFOS3YX9P5cLFW647bk037iQskBbeecdihxBvuecHgURRYm /zrA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1679456464; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=V3jUG0oglxMHUcZ7R/TmWEumXbeO4lDHFIDhwNqEDys=; b=y8phBu7T0bu84Sar1fXXA39ZEDXMJZkb8159XRBEhuIGWHJLnKfFiRbp+iR84nVOJF VihLag9rc2zHgLPuYk3yneq2qHKTsdXtjhwKAkkPkrkmRbmni7e8QOxV4fb/EkzYUG/P zbfuvuGo8qsxzKJUlfhqAZEGFtThRK+WSqzLkHoKonyhvYs0I0o9R8GjxpLFcZYABOPx 57zRccXdYVp8H53aM6jnPNhxgDD08+NtSZUY7+OKqbgkYdiWu9fAga2sKcoxiXv721a4 2rWgm6VkyAPAAmI9KjoW0QOw9SLRM3SC6RKAL4HdpLNRigM3npoQ6ZEQX7AjQE1FiBD7 Oi3g== X-Gm-Message-State: AAQBX9dkXGmVwUzQqYNA2lNzxKDYHUVFehK5heGIEbVubwgjuiHGBFpe y2anlrpbO/SoNxclOOYC1o+Xz9iumVB7CvBW4foaaY+Iicl6L2GosJy7OQ== X-Received: by 2002:a5b:c0d:0:b0:a02:a3a6:78fa with SMTP id f13-20020a5b0c0d000000b00a02a3a678famr2582824ybq.12.1679456464304; Tue, 21 Mar 2023 20:41:04 -0700 (PDT) MIME-Version: 1.0 References: <20230309170756.52927-1-cerasuolodomenico@gmail.com> <20230309170756.52927-4-cerasuolodomenico@gmail.com> In-Reply-To: From: Suren Baghdasaryan Date: Tue, 21 Mar 2023 20:40:52 -0700 Message-ID: Subject: Re: [PATCH 3/4] sched/psi: extract update_triggers side effect To: Domenico Cerasuolo Cc: linux-kernel@vger.kernel.org, peterz@infradead.org, brauner@kernel.org, chris@chrisdown.name, hannes@cmpxchg.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-15.7 required=5.0 tests=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,USER_IN_DEF_DKIM_WL, USER_IN_DEF_SPF_WL 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 On Tue, Mar 21, 2023 at 3:18=E2=80=AFAM Domenico Cerasuolo wrote: > > Hi Suren, thanks for all the feedback! This makes sense, I only have one = doubt, if we set update_total flag to window_update() and update_triggers()= , that flag would be ignored when the caller is psi_avgs_work(), this would= be happening in the next patch in the set. I don't see why the update_triggers part should be conceptually different between RT and unprivileged triggers. Could you please explain? > What do you think if I just remove this change from the patchset and then= work on a solution after the iterations on the main change are completed? = This was in fact just an attempt to clean up. > I'll apply your suggested changes on the other patches, wait a bit for co= mments from someone else and then send V2. > > On Tue, Mar 21, 2023 at 12:00=E2=80=AFAM Suren Baghdasaryan wrote: >> >> On Thu, Mar 9, 2023 at 9:08=E2=80=AFAM Domenico Cerasuolo >> wrote: >> > >> > The update of rtpoll_total inside update_triggers can be moved out of >> > the function since changed_states has the same information as the >> > update_total flag used in the function. Besides the simplification of >> > the function, with the next patch it would become an unwanted side >> > effect needed only for PSI_POLL. >> >> (changed_states & group->rtpoll_states) and update_total flag are not >> really equivalent. update_total flag depends on the difference between >> group->polling_total[state] and group->total[PSI_POLL][state] while >> changed_states depends on the difference between groupc->times and >> groupc->times_prev. groupc->times_prev is updated every time >> collect_percpu_times() is called and there are 3 places where that >> happens: from psi_avgs_work(), from psi_poll_work() and from >> psi_show(). group->polling_total[state] is updated only from >> psi_poll_work(). Therefore the deltas between these values might not >> always be in-sync. >> >> Consider the following sequence as an example: >> >> psi_poll_work() >> ... >> psi_avgs_work()/psi_show() >> collect_percpu_times() // we detect a change in a monitored state >> ... >> psi_poll_work() >> collect_percpu_times() // this time no change in monitored states >> update_triggers() // group->polling_total[state] !=3D >> group->total[PSI_POLL][state] >> >> In the last psi_poll_work() collect_percpu_times() recorded no change >> in monitored states, so (changed_states & group->rtpoll_states) =3D=3D 0= , >> however since the last time psi_poll_work() was called there was >> actually a change in monitored states recorded by the first >> collect_percpu_times(), therefore (group->polling_total[t->state] !=3D >> total[t->state]) and we should update the totals. With your change we >> will miss that update. >> >> I think you can easily fix that by introducing update_triggers as an >> output parameter in window_update() like this: >> >> static u64 window_update(struct psi_window *win, u64 now, u64 value, >> bool *update_triggers) { >> *update_total =3D false; >> ... >> if (new_stall) { >> *update_total =3D true; >> ... >> } >> >> static void psi_rtpoll_work(struct psi_group *group) { >> + bool update_triggers; >> ... >> - if (now >=3D group->rtpoll_next_update) >> + if (now >=3D group->rtpoll_next_update) { >> group->rtpoll_next_update =3D update_triggers(group, >> now, &update_triggers); >> + if (update_triggers) >> + memcpy(group->rtpoll_total, group->total[PSI_POL= L], >> + sizeof(group->rtpoll_total)); >> + } >> } >> >> >> > >> > Suggested-by: Johannes Weiner >> > Signed-off-by: Domenico Cerasuolo >> > --- >> > kernel/sched/psi.c | 20 +++++--------------- >> > 1 file changed, 5 insertions(+), 15 deletions(-) >> > >> > diff --git a/kernel/sched/psi.c b/kernel/sched/psi.c >> > index a3d0b5cf797a..476941c1cbea 100644 >> > --- a/kernel/sched/psi.c >> > +++ b/kernel/sched/psi.c >> > @@ -433,7 +433,6 @@ static u64 window_update(struct psi_window *win, u= 64 now, u64 value) >> > static u64 update_triggers(struct psi_group *group, u64 now) >> > { >> > struct psi_trigger *t; >> > - bool update_total =3D false; >> > u64 *total =3D group->total[PSI_POLL]; >> > >> > /* >> > @@ -456,14 +455,6 @@ static u64 update_triggers(struct psi_group *grou= p, u64 now) >> > * events without dropping any). >> > */ >> > if (new_stall) { >> > - /* >> > - * Multiple triggers might be looking at the s= ame state, >> > - * remember to update group->polling_total[] o= nce we've >> > - * been through all of them. Also remember to = extend the >> > - * polling time if we see new stall activity. >> > - */ >> > - update_total =3D true; >> > - >> > /* Calculate growth since last update */ >> > growth =3D window_update(&t->win, now, total[t= ->state]); >> > if (!t->pending_event) { >> > @@ -484,11 +475,6 @@ static u64 update_triggers(struct psi_group *grou= p, u64 now) >> > /* Reset threshold breach flag once event got generate= d */ >> > t->pending_event =3D false; >> > } >> > - >> > - if (update_total) >> > - memcpy(group->rtpoll_total, total, >> > - sizeof(group->rtpoll_total)); >> > - >> > return now + group->rtpoll_min_period; >> > } >> > >> > @@ -686,8 +672,12 @@ static void psi_rtpoll_work(struct psi_group *gro= up) >> > goto out; >> > } >> > >> > - if (now >=3D group->rtpoll_next_update) >> > + if (now >=3D group->rtpoll_next_update) { >> > group->rtpoll_next_update =3D update_triggers(group, n= ow); >> > + if (changed_states & group->rtpoll_states) >> > + memcpy(group->rtpoll_total, group->total[PSI_P= OLL], >> > + sizeof(group->rtpoll_total)); >> > + } >> > >> > psi_schedule_rtpoll_work(group, >> > nsecs_to_jiffies(group->rtpoll_next_update - now) + 1, >> > -- >> > 2.34.1 >> >