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;
Date:   Sat, 14 Jan 2023 23:59:39 +0800
From:   Chen Yu <yu.c.chen@intel.com>
To:     Andrei Vagin <avagin@gmail.com>
CC:     Andrei Vagin <avagin@google.com>,
        Peter Zijlstra <peterz@infradead.org>,
        Ingo Molnar <mingo@redhat.com>,
        Vincent Guittot <vincent.guittot@linaro.org>,
        Dietmar Eggemann <dietmar.eggemann@arm.com>,
        <linux-kernel@vger.kernel.org>, Kees Cook <keescook@chromium.org>,
        Christian Brauner <brauner@kernel.org>,
        Andy Lutomirski <luto@amacapital.net>,
        Juri Lelli <juri.lelli@redhat.com>,
        Peter Oskolkov <posk@google.com>,
        Tycho Andersen <tycho@tycho.pizza>,
        "Will Drewry" <wad@chromium.org>
Subject: Re: [PATCH 2/5] sched: add WF_CURRENT_CPU and externise ttwu
Message-ID: <Y8LRa/HJtZ/L2Shy@chenyu5-mobl1>
References: <20230110213010.2683185-1-avagin@google.com>
 <20230110213010.2683185-3-avagin@google.com>
 <Y7+4S9umCo5I+Ty7@chenyu5-mobl1>
 <CANaxB-wcpKS64q6_0+r+OwoZupRN-A-PQvPRiVsMmEgB1TRSrw@mail.gmail.com>
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <CANaxB-wcpKS64q6_0+r+OwoZupRN-A-PQvPRiVsMmEgB1TRSrw@mail.gmail.com>
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?CjB2z42m8NMGAQ0O+OfVaK4vR0gxZRZobdx+R6UjqmxnW61ViAuG5zj5HYCN?=
 =?us-ascii?Q?pKdeCJyBr5wKRDIbFBLD/w3Cb/Omt27TH3UKzik0ANXv3X07LNvDX3fojcM+?=
 =?us-ascii?Q?pwxTjjcHtzZcvHXQ09u9loA1/mxcNDZctfd9+tV4Q6Z01cKEROOEQOcuByBf?=
 =?us-ascii?Q?en4SFsPESiV5y3TkxWCwBDZfFsvq+YglF11aekKA6t2raaQJumlXzxQ63Pr4?=
 =?us-ascii?Q?jIAzza+bXdQXh41GUiPKjtq1ILDI7qIIdAOFrC9e3YHw1stWeP8TioryO3fz?=
 =?us-ascii?Q?+IZTkh8+4I+e5uDDXQICoof05mJYZ+64B8xhiV05FpZm9VkLkkWlMg7PO+OW?=
 =?us-ascii?Q?T19AeLKikl1c9jZ8AQzeYPp51FtrOzBAIRpDat8I8wTvfb64n0iAL/1BdGvi?=
 =?us-ascii?Q?6WkNvDeSd/YhqbS+5kBcrxsobz0pFfLhMTivx0lqEyXUHjAtIQEGhMV62F79?=
 =?us-ascii?Q?c9xvk1O4pfWXQbpnWefAfwbie8Ov/5olrxsbXHI9QvQtfl9QT2ZTg0T7G+tS?=
 =?us-ascii?Q?bJEn1ydK9GYvq8U6UEcn2/zaTZDIf8RThksBsnkvQBUj515HZbuCkD7JwFwg?=
 =?us-ascii?Q?PphaiIHSMzxC7QlcdJ0U4t4sO8JLRV/1J9i8xX1ZZBjqRAVkWdJc6e5Skn1A?=
 =?us-ascii?Q?H2UpUvCj4TdEMJ4cs3yZV9BPMgj0hw8Ue23es33k4HF6k9uv5SxTlD7FKePj?=
 =?us-ascii?Q?zdJd/AFfB2anUGmoTQfCEADMAx0wHb1ohfrHbPhhEyGs0WABIJzQOMRsWEDU?=
 =?us-ascii?Q?2PrtmvKaQkQ0H0VF7qUKwReeCFPbgYTZOqc20TziqwfT1FJYzMhQWIdUfzfi?=
 =?us-ascii?Q?c1sP4RRIUCBZsCeCCkDQ+4IC+5tomVjAn9RgzQjYoEkoqJdyEqmD3QD5Eqa3?=
 =?us-ascii?Q?fzt1UhvVqGfMz2d1zit+9ZdmeW8bfJdGYzkk6SSpNGG4s7GYd39NqU3kuxc2?=
 =?us-ascii?Q?03y8wd2nGuqr3MicM4MkjNv7vG3Pdm6kZgFDU+GdnOlhraZpKfFXtJjiqNTt?=
 =?us-ascii?Q?Po+8gSEZ73o1n5T/4aRoSxpx3+dtRNBUy1JRTcYpQu28D/CnAcp8lr++3qw+?=
 =?us-ascii?Q?zxLW+DodN26zPoUBq7vyYoVAbOAWwzoEH7O/4B60yAg1lBHsXXgIFWIfPEC/?=
 =?us-ascii?Q?V1L9NegdF/9smszLVhoEZCF3FvWfWoLPi/Nx1MekNRLNyCtkHNkhhnGv33NV?=
 =?us-ascii?Q?JuL8d/22BfDHre8psZxpF9KZplEoni0+f6pBHZr7LJ3snueZanAkNs0DxQQ5?=
 =?us-ascii?Q?Gjn3kk6Nx7Q6TaucrilTYXoJE0dWLCALAdTpDjy5VblRQLuRuZW7eNphboLM?=
 =?us-ascii?Q?VO+6CdRHGRGpPKXUOWALGuge3QxFLU5fl9IcP6DmJzmojdsA6p0Jaa+LcnaG?=
 =?us-ascii?Q?h0XBbfjBJomhSE5s0v85L/UxHWQzxSmYSf6GuYj3DmOix8i1FvbnU9tegbny?=
 =?us-ascii?Q?5mOaoL8qRudFZWlUo+WYSsoLBjaWxkQbwiU2vrpdA8vYYXOs3vl5m+gDC9xY?=
 =?us-ascii?Q?SVBz3L2C0bz+m4tssBr7fn9lKS//3BuOFFa6E0pbepwJbUx1j8taCoBd8T5c?=
 =?us-ascii?Q?99QDQkOAs9u5v+1CX5udzquhDhZ+AMYm3Xxts1FL?=
X-MS-Exchange-CrossTenant-Network-Message-Id: c720d012-123d-4453-36db-08daf648622d
X-MS-Exchange-CrossTenant-AuthSource: MN0PR11MB6206.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 14 Jan 2023 15:59:57.4523
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 46c98d88-e344-4ed4-8496-4ed7712e255d
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: vfSW1SnchjTcc9Urwk56bUJCV+hGR+TWtE196e4/Smwo6VbCxSecU+h+rgsuFJzJBIkG0egdhsFrVzk3qtA1CQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN7PR11MB6704
X-OriginatorOrg: intel.com
X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,
        DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_MED,
        SPF_HELO_NONE,SPF_NONE 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: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On 2023-01-13 at 13:39:46 -0800, Andrei Vagin wrote:
> On Wed, Jan 11, 2023 at 11:36 PM Chen Yu <yu.c.chen@intel.com> wrote:
> >
> > On 2023-01-10 at 13:30:07 -0800, Andrei Vagin wrote:
> > > From: Peter Oskolkov <posk@google.com>
> > >
> > > Add WF_CURRENT_CPU wake flag that advices the scheduler to
> > > move the wakee to the current CPU. This is useful for fast on-CPU
> > > context switching use cases.
> > >
> > > In addition, make ttwu external rather than static so that
> > > the flag could be passed to it from outside of sched/core.c.
> > >
> > > Signed-off-by: Peter Oskolkov <posk@google.com>
> > > Signed-off-by: Andrei Vagin <avagin@gmail.com>
> > > @@ -7380,6 +7380,10 @@ select_task_rq_fair(struct task_struct *p, int prev_cpu, int wake_flags)
> > >       if (wake_flags & WF_TTWU) {
> > >               record_wakee(p);
> > >
> > > +             if ((wake_flags & WF_CURRENT_CPU) &&
> > > +                 cpumask_test_cpu(cpu, p->cpus_ptr))
> > > +                     return cpu;
> > I agree that cross-CPU wake up brings pain to fast context switching
> > use cases,  especially on high core count system. We suffered from this
> > issue as well, so previously we presented this issue as well. The difference
> > is that we used some dynamic "WF_CURRENT_CPU" mechanism[1] to deal with it.
> > That is, if the waker/wakee are both short duration tasks, let the waker wakes up
> > the wakee on current CPU. So not only seccomp but also other components/workloads
> > could benefit from this without having to set the WF_CURRENT_CPU flag.
> >
> > Link [1]:
> > https://lore.kernel.org/lkml/cover.1671158588.git.yu.c.chen@intel.com/
> 
> Thanks for the link. I like the idea, but this change has no impact on the
> seccom notify case.  I used the benchmark from the fifth patch. It is
> a ping-pong
> benchmark in which one process triggers system calls, and another process
> handles them. It measures the number of system calls that can be processed
> within a specified time slice.
>
Thanks for this information.
> $ cd tools/testing/selftests/seccomp/
> $ make
> $ ./seccomp_bpf  2>&1| grep user_notification_sync
> #  RUN           global.user_notification_sync ...
> # seccomp_bpf.c:4281:user_notification_sync:basic: 8489 nsec/syscall
> # seccomp_bpf.c:4281:user_notification_sync:sync: 3078 nsec/syscall
> #            OK  global.user_notification_sync
> ok 51 global.user_notification_sync
> 
> The results are the same with and without your change. I expected that
> your change improves
> the basic case so that it reaches the sync one.
> 
The reason why the patch did not bring benefit might be that, that patch
aims to wake task on current CPU only there is no idle cores. The seccomp
notify would launch 2 processes which makes it hard to saturate the system
if I understand correctly? I built a kernel based on your repo, and launched
above test, it seems that the average load is quit low on my system. Is this
expected? Besides, is 100 ms long enough to test(USER_NOTIF_BENCH_TIMEOUT)?
> I did some experiments and found that we can achieve the desirable
> outcome if we move the "short-task" checks prior to considering waking
> up on prev_cpu.
> 
> For example, with this patch:
> 
> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> index 2f89e44e237d..af20b58e3972 100644
> --- a/kernel/sched/fair.c
> +++ b/kernel/sched/fair.c
> @@ -6384,6 +6384,11 @@ static int wake_wide(struct task_struct *p)
>  static int
>  wake_affine_idle(int this_cpu, int prev_cpu, int sync)
>  {
> +       /* The only running task is a short duration one. */
> +       if (cpu_rq(this_cpu)->nr_running == 1 &&
> +           is_short_task(cpu_curr(this_cpu)))
> +               return this_cpu;
> +
In v1 we put above code before checking the prev_cpu, but is was reported
to bring regression on some systems[2]. The result suggested that, we should
try to pick idle CPU first, no matter it is current CPU, or previous CPU,
if it failed, we can lower the bar and pick the current CPU.

[2] https://lore.kernel.org/lkml/6c626e8d-4133-00ba-a765-bafe08034517@amd.com/
>         /*
>          * If this_cpu is idle, it implies the wakeup is from interrupt
>          * context. Only allow the move if cache is shared. Otherwise an
> @@ -6405,11 +6410,6 @@ wake_affine_idle(int this_cpu, int prev_cpu, int sync)
>         if (available_idle_cpu(prev_cpu))
>                 return prev_cpu;
> 
> -       /* The only running task is a short duration one. */
> -       if (cpu_rq(this_cpu)->nr_running == 1 &&
> -           is_short_task(cpu_curr(this_cpu)))
> -               return this_cpu;
> -
>         return nr_cpumask_bits;
>  }
> 
> @@ -6897,6 +6897,10 @@ static int select_idle_sibling(struct
> task_struct *p, int prev, int target)
>             asym_fits_cpu(task_util, util_min, util_max, target))
>                 return target;
> 
> +       if (!has_idle_core && cpu_rq(target)->nr_running == 1 &&
> +           is_short_task(cpu_curr(target)) && is_short_task(p))
> +               return target;
> +
>         /*
>          * If the previous CPU is cache affine and idle, don't be stupid:
>          */
> 
> 
> the basic test case shows almost the same results as the sync one:
> 
> $ ./seccomp_bpf  2>&1| grep user_notification_sync
> #  RUN           global.user_notification_sync ...
> # seccomp_bpf.c:4281:user_notification_sync:basic: 3082 nsec/syscall
> # seccomp_bpf.c:4281:user_notification_sync:sync: 2690 nsec/syscall
> #            OK  global.user_notification_sync
> ok 51 global.user_notification_sync
> 
> If you want to do any experiments, you can find my tree here:
> [1] https://github.com/avagin/linux-task-diag/tree/wip/seccom-notify-sync-and-shed-short-task
> 
I'm happy to further test on this. One thing I'm curious about is, where does the
benefit of waking up seccom task on current CPU come from? Is it due to hot L1 cache?

thanks,
Chenyu
> Thanks,
> Andrei