Received: by 2002:a6b:fb09:0:0:0:0:0 with SMTP id h9csp1282492iog; Sat, 25 Jun 2022 05:34:50 -0700 (PDT) X-Google-Smtp-Source: AGRyM1vLaOC21BUEKMID3SZawnOFov9/3DdDY6kSUvqZqPVNQGaH8K+uScFgSkIYeJWA5QmONBf4 X-Received: by 2002:a17:90b:2245:b0:1ed:fef:5656 with SMTP id hk5-20020a17090b224500b001ed0fef5656mr4310930pjb.100.1656160489985; Sat, 25 Jun 2022 05:34:49 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1656160489; cv=none; d=google.com; s=arc-20160816; b=PuSOQ7s5yTLBSUJI7TSvb4Ai9GYyE2b+ddemkwsxuzWl9dU1uLwrZIunJC7bJQaiP6 jxXMfwxTvNXHK6le/eCk0zHiFsZ+hQzewpB8f7L6muXER8x9JWoTQwQOM/iDLD5LJWMI FuN/0VEUJksNfGiZa0yfmcKDXcLTO85BBt69d5dDf1TweZYfHyBO1m8F7Tb6JT4BmV+a sFaEY9YxkWxFEcIwFTrpIsb5YBYZkKvZr7pEOUbZLUt4fXi86YD/lwuy//JRThFELP18 89prwTQIikR3yXjetXZfCrYDfZFR9151JxmSdB9PmZw+GlW9/amvzvMDUsSkoUuRjr8c F1yg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=k6h1lNryS/PdYHAGF2+cQQNJ1h/8DZV/mIxN1ynumxA=; b=tEpTA/z5xx4/YYbPlkIB+Kbtrw6MLCr69QMrh46Jwqrv2lETODXc9cpMyvMYdYmJNk 3GbjZwmIsKDNHvUQ074oE/Rh+Y4yFP8KgE6vty2XXTtKToKtNxTgLiiWTc/Jo18bMSWF YzmhqEQD0V2WPmHi/j7N8lYGEQCG/R2zH8qKBXTABAf9NZkvo1aFKwAPr5nhudtPG+DK ObQBWgLHevJoI9yYaia3Nz/aifPu4BKv66kkQtNrje6UcCYKCV61PloTDp5DT2+K2Kwr 0NXQ8Lav7qbrxxtOTZUlWBoOUqk5QOb2e4gnCmsbW5JmWlH77+I8XI3mYj91Sb1zFQRP Pk1w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20210112 header.b=pxequgWi; 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=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id l73-20020a63914c000000b0040d2b457d5fsi6348067pge.274.2022.06.25.05.34.35; Sat, 25 Jun 2022 05:34:49 -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=@gmail.com header.s=20210112 header.b=pxequgWi; 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=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232933AbiFYMXS (ORCPT + 99 others); Sat, 25 Jun 2022 08:23:18 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:56894 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232929AbiFYMXR (ORCPT ); Sat, 25 Jun 2022 08:23:17 -0400 Received: from mail-wm1-x334.google.com (mail-wm1-x334.google.com [IPv6:2a00:1450:4864:20::334]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 94FD31116D for ; Sat, 25 Jun 2022 05:23:16 -0700 (PDT) Received: by mail-wm1-x334.google.com with SMTP id n185so2661325wmn.4 for ; Sat, 25 Jun 2022 05:23:16 -0700 (PDT) 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=k6h1lNryS/PdYHAGF2+cQQNJ1h/8DZV/mIxN1ynumxA=; b=pxequgWiSrF9utkbcYStNV/psctItI/TT2ldOQLHCimWwQ2vjFLyU7CWAWBWPoZ/X8 AixoHhTwZz3K2xJwXtmhgzIfx54BYtOGzz0T9KkGR7UGPE7yhSTnuvtTDKsFUQYUS3oG 2wBH2XfqLBeCRsc54EX0HS7pBfwFJv6VROO8xguckeAOA5r+ZSbmlPb6RA6TsgHplY+K rWZuFSpPe2uUUe7v+mV2MDOHkeMMVQ+/HQvNnurE+uqdQ7bq1J+wezGE4utoRxVMh8SV aJfW30abWARmVdqTmN6/7pFwZAWikO/X9HtSeTr04F7Yk7Jw1nM1vMQHGKKsblnZKiZf t4Kg== 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=k6h1lNryS/PdYHAGF2+cQQNJ1h/8DZV/mIxN1ynumxA=; b=7qCoQxHibtCwZ8/mMpHOnOD0XjjIjq0baB4FCOmRQzpRVG8LkeXzgwDzhzSbIR6aIg Dpc9HQZOSGJYnSab9UDFfIo3TEB40NrZaAcj2k/mCMrsCjZS9SRPvw0vZYJuumY0opoV F3Yp7WW5jmAxC4VensbhGxAXvsHUr4IrEdRz/3OVYevz8/KyWqb79aRkFhohH5BSDTqM ya5XNiBqhCvJFzcURNeTg1CDAqNAKLS4EOp6ueGj5GH2P7sQ5aBSdK5UJvvdO883jEle 9dQjJKGjr+Kwp16fqQjZ/oNEsYfZjaP4vxoUOvdLCSvseZOo7G2grEtkrqUi4IG+6iBh osoQ== X-Gm-Message-State: AJIora9GvUDaiv1M/gDL/wPMsN1vNGuGUaY6a2nXuGucM2P0uSPmw3Ow r8M8g+yHDplECSpSz+8IRZQ1IXrtXp14wEnSSFw= X-Received: by 2002:a7b:c188:0:b0:3a0:391d:45f4 with SMTP id y8-20020a7bc188000000b003a0391d45f4mr8836258wmi.11.1656159794971; Sat, 25 Jun 2022 05:23:14 -0700 (PDT) MIME-Version: 1.0 References: <20220623182932.58589-1-schspa@gmail.com> In-Reply-To: From: Schspa Shi Date: Sat, 25 Jun 2022 20:23:03 +0800 Message-ID: Subject: Re: [PATCH] sched: fix bad task migration for rt tasks To: Valentin Schneider Cc: mingo@redhat.com, peterz@infradead.org, juri.lelli@redhat.com, vincent.guittot@linaro.org, dietmar.eggemann@arm.com, rostedt@goodmis.org, Benjamin Segall , mgorman@suse.de, bristot@redhat.com, Linux Kernel Mailing List Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM, RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE 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: X-Mailing-List: linux-kernel@vger.kernel.org Valentin Schneider writes: > On 24/06/22 02:29, Schspa Shi wrote: >> @@ -1998,12 +1998,15 @@ static struct rq *find_lock_lowest_rq(struct task_struct *task, struct rq *rq) >> * the mean time, task could have >> * migrated already or had its affinity changed. >> * Also make sure that it wasn't scheduled on its rq. >> + * It is possible the task has running for a while, >> + * And we check task migration disable flag again. >> */ >> if (unlikely(task_rq(task) != rq || >> !cpumask_test_cpu(lowest_rq->cpu, &task->cpus_mask) || > > cf. 95158a89dd50 ("sched,rt: Use the full cpumask for balancing"), this > made sense to me back then but not so much anymore... Shouldn't this have > remained a ->cpus_ptr check? > It seems it is for the following scenarios: It allows the higher priority non migratable task to be sched quickly by migrating the current task to another CPU with lower priority. Considering this, we should retry for this. rather than return with no lower priority rq. I can upload a new patchset for this handing. Please refers to the fellowing code: if (is_migration_disabled(next_task)) { struct task_struct *push_task = NULL; int cpu; if (!pull || rq->push_busy) return 0; /* * Invoking find_lowest_rq() on anything but an RT task doesn't * make sense. Per the above priority check, curr has to * be of higher priority than next_task, so no need to * reschedule when bailing out. * * Note that the stoppers are masqueraded as SCHED_FIFO * (cf. sched_set_stop_task()), so we can't rely on rt_task(). */ if (rq->curr->sched_class != &rt_sched_class) return 0; cpu = find_lowest_rq(rq->curr); if (cpu == -1 || cpu == rq->cpu) return 0; /* * Given we found a CPU with lower priority than @next_task, * therefore it should be running. However we cannot migrate it * to this other CPU, instead attempt to push the current * running task on this CPU away. */ push_task = get_push_task(rq); if (push_task) { raw_spin_rq_unlock(rq); stop_one_cpu_nowait(rq->cpu, push_cpu_stop, push_task, &rq->push_work); raw_spin_rq_lock(rq); } return 0; } > I'm going to revisit that commit, I evicted too much of it. > >> task_running(rq, task) || >> !rt_task(task) || >> - !task_on_rq_queued(task))) { >> + !task_on_rq_queued(task) || >> + is_migration_disabled(task))) { >> >> double_unlock_balance(rq, lowest_rq); >> lowest_rq = NULL; >> -- >> 2.24.3 (Apple Git-128) -- BRs Schspa Shi