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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id F364EC433FE for ; Mon, 30 May 2022 16:24:17 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S241720AbiE3QYP (ORCPT ); Mon, 30 May 2022 12:24:15 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39180 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S241825AbiE3QYL (ORCPT ); Mon, 30 May 2022 12:24:11 -0400 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id E521B980B4 for ; Mon, 30 May 2022 09:24:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1653927850; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=c51AIok/qwJiPHR0blC8qWUmAJd+ZhA5KSNEkPpkepM=; b=RgrKCUzMqzpxY04NGvX1xx72WF7wePNbRG6y4SaFojc/FbRPHWO0rW812/5TAdVqohB41A jEmG/J+ulmTOROxXo95uEaCO7q9yuMBBUmi1s3EVQ/PJP9e1t1y/G6jxIt/qJto7riuRUC ba3GyW2FzNPTb3WIWwoIKZpRXydZPTM= Received: from mail-wr1-f69.google.com (mail-wr1-f69.google.com [209.85.221.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-486-7OdMNw05OSKfMIEncxA8ZA-1; Mon, 30 May 2022 12:24:08 -0400 X-MC-Unique: 7OdMNw05OSKfMIEncxA8ZA-1 Received: by mail-wr1-f69.google.com with SMTP id bv12-20020a0560001f0c00b0020e359b3852so1660088wrb.14 for ; Mon, 30 May 2022 09:24:08 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:in-reply-to:references:date :message-id:mime-version; bh=c51AIok/qwJiPHR0blC8qWUmAJd+ZhA5KSNEkPpkepM=; b=ZQ6WkM/5ZPSCb8TNQPlWVDqkIIrRnROxQezFAKFGcdcDSpcM5vf9Jks/u8M4ln/zTN 7qXNh56Nxb9IwQ9Lt5QRsVOtP3axyQR4xzGuamQjqdPBLduvGOnHxvqBRdkwCBZd8BgS uXh25k2ZZ0dPW32AuIpUaYHI9x0zqN+1qkJANT1nnvLPKDFNh+yKO5Pw5+TkUD92fcet BTBv6eDNGfrZMAHkaIYYxCBc8bPOxaCTWKZH3yQL0pJxqQxB2tyM1gFlan3tlZ9c8tgz uwNEk+lIwW4LFiaL5m3yiZdgjoOJqSR0jjRiLswvo5UP3hCHNhDS1+gMVNRCVKdT5cIt z8aw== X-Gm-Message-State: AOAM53122MqmWdDr1uWq9hKGFXXrWNDJwLnzayX7/4DkgbndVU+orb5Z aRRnu8d//sgTLC96EVoTQh4rwhJxvrvxi8mOgVlWz0mGXYd2BcKr8DUFHbLWVIwStqpJsHEIqGB buuWjQuKn01qnzlUHE9p9kBn6b4gqYW+HBUSXFW6GPNP7UfuEnUDDVxjqWu31g5B5baoZdNuKa9 L1 X-Received: by 2002:a5d:6dd1:0:b0:210:7a1:cda0 with SMTP id d17-20020a5d6dd1000000b0021007a1cda0mr18680270wrz.570.1653927847397; Mon, 30 May 2022 09:24:07 -0700 (PDT) X-Google-Smtp-Source: ABdhPJy4LyWcDXBw/1y8ErZsQrrcFmUeOOWeEdDjJjGs5Cw8r/JnDZF53lhn1G6g0YbhRUeUopFGvw== X-Received: by 2002:a5d:6dd1:0:b0:210:7a1:cda0 with SMTP id d17-20020a5d6dd1000000b0021007a1cda0mr18680245wrz.570.1653927847122; Mon, 30 May 2022 09:24:07 -0700 (PDT) Received: from vschneid.remote.csb ([185.11.37.247]) by smtp.gmail.com with ESMTPSA id r4-20020a1c2b04000000b003973c4bb19bsm10694681wmr.16.2022.05.30.09.24.06 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 30 May 2022 09:24:06 -0700 (PDT) From: Valentin Schneider To: Tianchen Ding , Ingo Molnar , Peter Zijlstra , Juri Lelli , Vincent Guittot , Dietmar Eggemann , Steven Rostedt , Ben Segall , Mel Gorman , Daniel Bristot de Oliveira Cc: linux-kernel@vger.kernel.org Subject: Re: [PATCH v2] sched: Queue task on wakelist in the same llc if the wakee cpu is idle In-Reply-To: <20220527090544.527411-1-dtcccc@linux.alibaba.com> References: <20220527090544.527411-1-dtcccc@linux.alibaba.com> Date: Mon, 30 May 2022 17:24:05 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 27/05/22 17:05, Tianchen Ding wrote: > The main idea of wakelist is to avoid cache bouncing. However, > commit 518cd6234178 ("sched: Only queue remote wakeups when > crossing cache boundaries") disabled queuing tasks on wakelist when > the cpus share llc. This is because, at that time, the scheduler must > send IPIs to do ttwu_queue_wakelist. Nowadays, ttwu_queue_wakelist also > supports TIF_POLLING, so this is not a problem now when the wakee cpu is > in idle polling. [...] > Our patch has improvement on schbench, hackbench > and Pipe-based Context Switching of unixbench > when there exists idle cpus, > and no obvious regression on other tests of unixbench. > This can help improve rt in scenes where wakeup happens frequently. > > Signed-off-by: Tianchen Ding This feels a bit like a generalization of 2ebb17717550 ("sched/core: Offload wakee task activation if it the wakee is descheduling") Given rq->curr is updated before prev->on_cpu is cleared, the waker executing ttwu_queue_cond() can observe: p->on_rq=0 p->on_cpu=1 rq->curr=swapper/x (aka idle task) So your addition of available_idle_cpu() in ttwu_queue_cond() (sort of) matches that when invoked via: if (smp_load_acquire(&p->on_cpu) && ttwu_queue_wakelist(p, task_cpu(p), wake_flags | WF_ON_CPU)) goto unlock; but it also affects ttwu_queue(p, cpu, wake_flags); at the tail end of try_to_wake_up(). With all that in mind, I'm curious whether your patch is functionaly close to the below. --- diff --git a/kernel/sched/core.c b/kernel/sched/core.c index 66c4e5922fe1..ffd43264722a 100644 --- a/kernel/sched/core.c +++ b/kernel/sched/core.c @@ -3836,7 +3836,7 @@ static inline bool ttwu_queue_cond(int cpu, int wake_flags) * the soon-to-be-idle CPU as the current CPU is likely busy. * nr_running is checked to avoid unnecessary task stacking. */ - if ((wake_flags & WF_ON_CPU) && cpu_rq(cpu)->nr_running <= 1) + if (cpu_rq(cpu)->nr_running <= 1) return true; return false;