[{"id":3677293,"web_url":"http://patchwork.ozlabs.org/comment/3677293/","msgid":"","list_archive_url":null,"date":"2026-04-14T15:54:49","subject":"Re: [LTP] [PATCH] sched_football: fix false failures on many-CPU\n systems","submitter":{"id":90848,"url":"http://patchwork.ozlabs.org/api/people/90848/","name":"Jan Polensky","email":"japo@linux.ibm.com"},"content":"On Sun, Apr 12, 2026 at 06:35:42PM +0530, Soma Das wrote:\n> Test logs attached — 40+ consecutive runs passing after fix on 80-CPU\n> ppc64le LPAR. ---\n> From 3fc17dd06907785f5b1b65aebfe150c8ac73d54a Mon Sep 17 00:00:00 2001\n> From: Soma Das \n> Date: Sun, 12 Apr 2026 13:13:08 +0000\n> Subject: [PATCH] sched_football: fix false failures on many-CPU systems\n> On large SMP systems with CONFIG_RT_GROUP_SCHED=n, four independent\n> issues cause false failures.\n> 1. RT throttling freezes all SCHED_FIFO threads simultaneously. On\n> release, the kernel does not always reschedule the highest-priority\n> thread first on every CPU, so offense briefly runs and increments\n> the_ball before defense is rescheduled. Fix by saving and disabling\n> sched_rt_runtime_us in setup and restoring it in a new cleanup\n> callback.\n> 2. Offense and defense threads were unpinned, allowing the scheduler\n> to migrate them freely. An offense thread could land on a CPU with\n> no defense thread present and run unchecked. Fix by passing a CPU\n> index as the thread arg and calling sched_setaffinity() at thread\n> start. Pairs are distributed round-robin (i % ncpus) so each\n> offense thread shares its CPU with a defense thread.\n> 3. game_over was never reset between iterations, causing all threads\n> to exit immediately on reruns (-i N), making the test a no-op.\n> Fix by resetting both kickoff_flag and game_over at the top of\n> do_test().\n> 4. sched_setscheduler() failure for the referee was silently ignored.\n> If the call fails the test produces meaningless results. Fix by\n> checking the return value and calling tst_brk(TBROK) on failure.\n> Signed-off-by: Soma Das \n> ---\n[snip]\nHi Soma,\n\nthis patch makes the test much more deterministic by changing the\nscheduling scenario: offense/defense were previously unpinned (so they\ncould migrate freely), but are now pinned via sched_setaffinity() with\nexplicit CPU pairing (round‑robin across CPUs).\n\nThat likely fixes the false failures you describe (offense briefly\nrunning “unchecked” when it lands on a CPU without a local higher‑prio\ndefense), but it also means we’re no longer exercising\nmigration/load‑balancing behavior here.\n\nWe’re effectively testing local SCHED_FIFO priority ordering under\ncontrolled placement. It would be great to call this out explicitly in\nthe test description / commit message so readers don’t assume the test\nstill covers migration fairness.\n\nTested-by: Jan Polensky \n\nTested on z16:\n\n [************ ~]# lscpu\n Architecture: s390x\n CPU op-mode(s): 32-bit, 64-bit\n Byte Order: Big Endian\n CPU(s): 256\n On-line CPU(s) list: 0-255\n Vendor ID: IBM/S390\n Model name: -\n Machine type: 9175\n Thread(s) per core: 2\n[snip]\n\nBest regards\nJan","headers":{"Return-Path":"","X-Original-To":["incoming@patchwork.ozlabs.org","ltp@lists.linux.it"],"Delivered-To":["patchwork-incoming@legolas.ozlabs.org","ltp@picard.linux.it"],"Authentication-Results":["legolas.ozlabs.org;\n\tdkim=fail reason=\"signature verification failed\" (2048-bit key;\n unprotected) header.d=ibm.com header.i=@ibm.com header.a=rsa-sha256\n header.s=pp1 header.b=DdKOhtSE;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=lists.linux.it\n (client-ip=2001:1418:10:5::2; helo=picard.linux.it;\n envelope-from=ltp-bounces+incoming=patchwork.ozlabs.org@lists.linux.it;\n receiver=patchwork.ozlabs.org)"],"Received":["from picard.linux.it (picard.linux.it [IPv6:2001:1418:10:5::2])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange x25519 server-signature ECDSA (secp384r1) server-digest SHA384)\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4fw84L58mXz1yHH\n\tfor ; Wed, 15 Apr 2026 01:55:12 +1000 (AEST)","from picard.linux.it (localhost [IPv6:::1])\n\tby picard.linux.it (Postfix) with ESMTP id 62FAE3E5DC7\n\tfor ; Tue, 14 Apr 2026 17:55:02 +0200 (CEST)","from in-2.smtp.seeweb.it (in-2.smtp.seeweb.it [217.194.8.2])\n (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n key-exchange X25519 server-signature ECDSA (secp384r1))\n (No client certificate requested)\n by picard.linux.it (Postfix) with ESMTPS id 26A603E2939\n for ; Tue, 14 Apr 2026 17:54:59 +0200 (CEST)","from mx0a-001b2d01.pphosted.com (mx0a-001b2d01.pphosted.com\n [148.163.156.1])\n (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest\n SHA256)\n (No client certificate requested)\n by in-2.smtp.seeweb.it (Postfix) with ESMTPS id 3B82E6003BC\n for ; Tue, 14 Apr 2026 17:54:57 +0200 (CEST)","from pps.filterd (m0356517.ppops.net [127.0.0.1])\n by mx0a-001b2d01.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id\n 63EEITmM1833259\n for ; Tue, 14 Apr 2026 15:54:56 GMT","from ppma22.wdc07v.mail.ibm.com\n (5c.69.3da9.ip4.static.sl-reverse.com [169.61.105.92])\n by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 4dh89rbmkj-1\n (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT)\n for ; Tue, 14 Apr 2026 15:54:55 +0000 (GMT)","from pps.filterd (ppma22.wdc07v.mail.ibm.com [127.0.0.1])\n by ppma22.wdc07v.mail.ibm.com (8.18.1.2/8.18.1.2) with ESMTP id\n 63EDvIAV031099\n for ; Tue, 14 Apr 2026 15:54:54 GMT","from smtprelay02.fra02v.mail.ibm.com ([9.218.2.226])\n by ppma22.wdc07v.mail.ibm.com (PPS) with ESMTPS id 4dg10yabkr-1\n (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT)\n for ; Tue, 14 Apr 2026 15:54:54 +0000","from smtpav02.fra02v.mail.ibm.com (smtpav02.fra02v.mail.ibm.com\n [10.20.54.101])\n by smtprelay02.fra02v.mail.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id\n 63EFsoiF46268740\n (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);\n Tue, 14 Apr 2026 15:54:50 GMT","from smtpav02.fra02v.mail.ibm.com (unknown [127.0.0.1])\n by IMSVA (Postfix) with ESMTP id D192D20043;\n Tue, 14 Apr 2026 15:54:50 +0000 (GMT)","from smtpav02.fra02v.mail.ibm.com (unknown [127.0.0.1])\n by IMSVA (Postfix) with ESMTP id 97D7320040;\n Tue, 14 Apr 2026 15:54:50 +0000 (GMT)","from li-276bd24c-2dcc-11b2-a85c-945b6f05615c.ibm.com (unknown\n [9.111.2.172]) by smtpav02.fra02v.mail.ibm.com (Postfix) with ESMTPS;\n Tue, 14 Apr 2026 15:54:50 +0000 (GMT)"],"DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed; d=ibm.com; h=\n content-transfer-encoding:content-type:date:from:in-reply-to\n :message-id:mime-version:references:subject:to; s=pp1; bh=dZZ88B\n gSTzqYUSvTwh4oiqiOYGmJcRv9byDOaWpsybg=; b=DdKOhtSEq0/n1pzF4eRq48\n vK53J+GX39PqijTiAGAnSGh5Gdv9D9Mk9Zld78j+HVRt/9FmEUiDG+MEYKI63nBt\n ZS2oNLzC1Wy0yNF9ssS/6R3FXLKzNAxCalNLWpIS4JUTBK1iC5fAwFK43xO2FjH1\n tLHTJJDfDWTdwg1V6pIYgy2Ctj3SjFjWgJG6ObdzAzk4G+tvKSAvC0F/dwqHUUdJ\n JardcOZhVw8Qb/3Nuth8o0XME+HmmIuJVYjdG3VqN4Y5q1yA/4B6awLT6ANblKEy\n CwheP0Hx7qemmki0fHo6GL9k9mg51nhNTs0sApi8Pxr4SwC5PoFju2njTQdGATTQ\n ==","Date":"Tue, 14 Apr 2026 17:54:49 +0200","From":"Jan Polensky ","To":"Soma Das , ltp@lists.linux.it","Message-ID":"","References":"<53f26493-09fc-4f8b-9751-24d2c2e80697@linux.ibm.com>","MIME-Version":"1.0","Content-Disposition":"inline","In-Reply-To":"<53f26493-09fc-4f8b-9751-24d2c2e80697@linux.ibm.com>","X-TM-AS-GCONF":"00","X-Proofpoint-Spam-Details-Enc":"AW1haW4tMjYwNDE0MDE0OCBTYWx0ZWRfX/ulH+UtUhAIN\n 2iCp6I956wvOxzxcZsw4xpIjaELG7JtbcW9M9MT4WtzWeTuFoUt+BHoY/I9ZW1y6PL7iAWF2uro\n 3b39W5+SukwwE+kZi3zwt8DfNx+8pr27zSRJBWApvctaQ8Q2bfXm7xR+SXnMmRavhZaCL+4FtWM\n EW5FPqAXHkfB3z0dM77WzFQ3p3y1JQ9ibmJw73Pu2UjmZvprJ4gF6l21+HuhodNJbHQfuT8IkTx\n o+imuUL60AAlAxUjtA8sI8pnxUgkZApvuNObupRYDMJVykHEBPiEtJ+V2nKmPEp9X37JFuH1nmk\n tR6qoc/RDY7YdgmAF/jbJwzyM+UerV3HDUTkQ0bnnEgTk/BJarBF9BZteEh2w/fzNq5BbnDeosm\n y0jsG5/k0MFwRRqLjsPBBzn5z4dX0XrIMd9jpraKiIVNh/VvX+qrYK+M7pg8EzFICu5Sfz9fdqt\n mW7Tla/Uw+D8yXzHyXw==","X-Proofpoint-ORIG-GUID":"jbCr8H29153z2SYon1FR_LD0h6-x8rFQ","X-Proofpoint-GUID":"jbCr8H29153z2SYon1FR_LD0h6-x8rFQ","X-Authority-Analysis":"v=2.4 cv=fYidDUQF c=1 sm=1 tr=0 ts=69de634f cx=c_pps\n a=5BHTudwdYE3Te8bg5FgnPg==:117 a=5BHTudwdYE3Te8bg5FgnPg==:17\n a=IkcTkHD0fZMA:10 a=A5OVakUREuEA:10 a=VkNPw1HP01LnGYTKEx00:22\n a=RnoormkPH1_aCDwRdu11:22 a=U7nrCbtTmkRpXpFmAIza:22 a=VnNF1IyMAAAA:8\n a=xtmZHlQmzooOEY0VdzoA:9 a=3ZKOabzyN94A:10 a=QEXdDO2ut3YA:10","X-Proofpoint-Virus-Version":"vendor=baseguard\n engine=ICAP:2.0.293,Aquarius:18.0.1143,Hydra:6.1.51,FMLib:17.12.100.49\n definitions=2026-04-14_03,2026-04-13_04,2025-10-01_01","X-Proofpoint-Spam-Details":"rule=outbound_notspam policy=outbound score=0\n adultscore=0 impostorscore=0 clxscore=1015 malwarescore=0 phishscore=0\n bulkscore=0 priorityscore=1501 spamscore=0 suspectscore=0 lowpriorityscore=0\n classifier=typeunknown authscore=0 authtc= authcc= route=outbound adjust=0\n reason=mlx scancount=1 engine=8.22.0-2604070000 definitions=main-2604140148","X-Spam-Status":"No, score=0.1 required=7.0 tests=DKIM_SIGNED,DKIM_VALID,\n DMARC_PASS,SPF_HELO_NONE,SPF_PASS shortcircuit=no autolearn=disabled\n version=4.0.1","X-Spam-Checker-Version":"SpamAssassin 4.0.1 (2024-03-25) on in-2.smtp.seeweb.it","X-Virus-Scanned":"clamav-milter 1.0.9 at in-2.smtp.seeweb.it","X-Virus-Status":"Clean","Subject":"Re: [LTP] [PATCH] sched_football: fix false failures on many-CPU\n systems","X-BeenThere":"ltp@lists.linux.it","X-Mailman-Version":"2.1.29","Precedence":"list","List-Id":"Linux Test Project ","List-Unsubscribe":",\n ","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n ","Content-Type":"text/plain; charset=\"utf-8\"","Content-Transfer-Encoding":"base64","Errors-To":"ltp-bounces+incoming=patchwork.ozlabs.org@lists.linux.it","Sender":"\"ltp\" "}},{"id":3677315,"web_url":"http://patchwork.ozlabs.org/comment/3677315/","msgid":"<20260414165956.4038-1-linuxtestproject.agent@gmail.com>","list_archive_url":null,"date":"2026-04-14T16:59:56","subject":"Re: [LTP] sched_football: fix false failures on many-CPU systems","submitter":{"id":93132,"url":"http://patchwork.ozlabs.org/api/people/93132/","name":null,"email":"linuxtestproject.agent@gmail.com"},"content":"Hi Soma,\n\nOn Sun, 12 Apr 2026 13:13:08 +0000, Soma Das wrote:\n> sched_football: fix false failures on many-CPU systems\n>\n> On large SMP systems with CONFIG_RT_GROUP_SCHED=n, four independent\n> issues cause false failures.\n>\n> 1. RT throttling...\n> 2. Offense and defense threads were unpinned...\n> 3. game_over was never reset between iterations...\n> 4. sched_setscheduler() failure for the referee was silently ignored.\n\nThe commit message itself describes these as four independent issues.\nPlease split into four separate commits so bisection and backporting\nwork correctly. At minimum, fixes 3 (game_over reset between -i\niterations) and 4 (sched_setscheduler error check) are fully orthogonal\nto the RT-throttling and CPU-affinity changes and must be separate\npatches.\n\n[...]\n\n> +\tSAFE_FILE_SCANF(\"/proc/sys/kernel/sched_rt_runtime_us\", \"%ld\",\n> +\t\t\t&saved_rt_runtime_us);\n> ...\n> +\tSAFE_FILE_PRINTF(\"/proc/sys/kernel/sched_rt_runtime_us\", \"%ld\", -1L);\n\nConsider using .save_restore in struct tst_test instead of manual\nsave/restore in setup/cleanup — it is the idiomatic LTP approach for\n/proc/sys knobs.\n\n---\nNote:\n\nOur agent completed the review of the patch. The agent can sometimes\nproduce false positives although often its findings are genuine. If you\nfind issues with the review, please comment this email or ignore the\nsuggestions.\n\nRegards,\nLTP AI Reviewer","headers":{"Return-Path":"","X-Original-To":["incoming@patchwork.ozlabs.org","ltp@lists.linux.it"],"Delivered-To":["patchwork-incoming@legolas.ozlabs.org","ltp@picard.linux.it"],"Authentication-Results":["legolas.ozlabs.org;\n\tdkim=fail reason=\"signature verification failed\" (2048-bit key;\n unprotected) header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256\n header.s=20251104 header.b=H2s6N/kn;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=lists.linux.it\n (client-ip=2001:1418:10:5::2; helo=picard.linux.it;\n envelope-from=ltp-bounces+incoming=patchwork.ozlabs.org@lists.linux.it;\n receiver=patchwork.ozlabs.org)"],"Received":["from picard.linux.it (picard.linux.it [IPv6:2001:1418:10:5::2])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange x25519)\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4fw9WB1Fkwz1xtJ\n\tfor ; Wed, 15 Apr 2026 03:00:06 +1000 (AEST)","from picard.linux.it (localhost [IPv6:::1])\n\tby picard.linux.it (Postfix) with ESMTP id 248023E5E00\n\tfor ; Tue, 14 Apr 2026 19:00:03 +0200 (CEST)","from in-2.smtp.seeweb.it (in-2.smtp.seeweb.it [217.194.8.2])\n (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n key-exchange X25519 server-signature ECDSA (secp384r1))\n (No client certificate requested)\n by picard.linux.it (Postfix) with ESMTPS id 998AF3CDC78\n for ; Tue, 14 Apr 2026 18:59:59 +0200 (CEST)","from mail-oi1-x242.google.com (mail-oi1-x242.google.com\n [IPv6:2607:f8b0:4864:20::242])\n (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)\n key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest\n SHA256)\n (No client certificate requested)\n by in-2.smtp.seeweb.it (Postfix) with ESMTPS id 1DFB7600702\n for ; Tue, 14 Apr 2026 18:59:59 +0200 (CEST)","by mail-oi1-x242.google.com with SMTP id\n 5614622812f47-470145d7df5so3538749b6e.0\n for ; Tue, 14 Apr 2026 09:59:59 -0700 (PDT)","from\n runnervm35a4x.kkizw1q41lvuhazfqxg01mu2mg.gx.internal.cloudapp.net\n ([172.212.163.19]) by smtp.gmail.com with ESMTPSA id\n 5614622812f47-478a0f1e841sm7879375b6e.5.2026.04.14.09.59.56\n (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);\n Tue, 14 Apr 2026 09:59:57 -0700 (PDT)"],"DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n d=gmail.com; s=20251104; t=1776185998; x=1776790798; darn=lists.linux.it;\n h=content-transfer-encoding:mime-version:references:in-reply-to\n :message-id:date:subject:cc:to:from:from:to:cc:subject:date\n :message-id:reply-to;\n bh=0RqwFWXA1r9C/qrxiI4Z6Cloe1c/7fkWOtsHTQZlJQA=;\n b=H2s6N/knr3tpJjRbdIVQ8Wp1vvLXhA/DTe62zD55jPELnSMV1aEgCKFvAiK6PCSkU7\n 9gGUPMvsHkCxHzMTN19MMgNu/zVnWhNyaEcyRTeJ6Se6L+QNTrjgR5pvw/TDWZZ7q9FK\n iUSczqQXH3qPv59jhuPaMYy6ngP2tal4cTZVFuHK8fpbXKrJaMxAIrNhBhtwRAQ/G6+R\n 8YEARrLmfFSntwhgfD2QC7gvBJPo4RfcxjuLI97HRq3Ag1CWK3qx+H6ak0QBaDxDhc/k\n 9DHDUUkxpz0ilajtu+ZfhxUgSgLGbcQNzzp/wcvssT+SvEIUFltOiSP5ZObaLLs1mkdH\n XGmg==","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n d=1e100.net; s=20251104; t=1776185998; x=1776790798;\n h=content-transfer-encoding:mime-version:references:in-reply-to\n :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from\n :to:cc:subject:date:message-id:reply-to;\n bh=0RqwFWXA1r9C/qrxiI4Z6Cloe1c/7fkWOtsHTQZlJQA=;\n b=jJapk59rbDRZR444VorLTRyvEbYKUZEwmwrZcgDRCl8QSeMzIA525L7M6ODkuQayzf\n 0XIAFSDBy+fpmLargZGlFEHl2f1mzFB5bdYEvTRJzDZ3er4qEwqQs2GdnQhEuKCbSTOh\n nw6gPzb+QmgLS3CC+4SJXdY/8hYTtDT3arExsIqHFxMCASFxQEFPSEVhbphXGqIhwIdd\n AAH7V3Rkv/14Fstkwy5uQqXUUH+pW6uOMRm8UdBMFNyRo/1J6wN9TnAkfvqbbuNexFLL\n 8k3UNNeXn9pgUYl0sR8KuIg63cTuPwX7hH7VN2p7VcdJ0Akc9dBtYqUkGp+W7M/Uphk/\n KJ8w==","X-Gm-Message-State":"AOJu0YxZydHWLa44inqrcMOgHHwX0zd9UPWuvHgo4q0xoVBiyGqc5/qS\n v0dfAY5oQfEDCQXqL6m5IPoCWRCI7I+lInSi3D5e8FA2rOSie0aFoWrN","X-Gm-Gg":"AeBDiesNRAEudXItPvWd25JkCesKxMf9oSlj8zDlpBce9rZUOYTBgW2bBdR5D9kURNJ\n IGs+bA1CHHzCntgzVj9DAoPJLfXAXkBGuzcvSCrpRvsfHh+o2aYzOh+ceM69QYsb6LBX6Fr7GJN\n qnwJC49XAN/b2/r3boUng2pP4o8zwrUYFr69rSmmrgP2mLXA3GX1p3tJdS81qGN0ARIAmerVERu\n sh+zUiYIsrDx3/1zT6gcq134aiNTdksZVmEI3iiOcEkWaEjEmnHfr6yFnXbG2lBol6tKlQznV6A\n D1mbNo8cxAlNmZSa3ILN8+FU/CzWzoPIg5151eIIiuFUgdxdC14SSY2YvAtFQjkQQ2sPJRA1mzK\n vP5BeExJP25fW0aOo813wiSN/aZjf87Rbm5lwbd2kwdEB7kfEMv+dKGWiEFuJL6coJFvMup4QnB\n sRFMFmZGunVILASSjd40H6aOvb/yjBQoHBNwSg/+3RcmAKxRGxq6IM8CoqV7t/wB3NnDOxhkLh1\n vF6ubU2SrVVDbRiYloo8//MAA==","X-Received":"by 2002:a05:6808:1a25:b0:46a:e0cd:2723 with SMTP id\n 5614622812f47-4789d73d0b5mr8644031b6e.21.1776185997654;\n Tue, 14 Apr 2026 09:59:57 -0700 (PDT)","From":"linuxtestproject.agent@gmail.com","To":"Soma Das ","Date":"Tue, 14 Apr 2026 16:59:56 +0000","Message-ID":"<20260414165956.4038-1-linuxtestproject.agent@gmail.com>","X-Mailer":"git-send-email 2.53.0","In-Reply-To":"<53f26493-09fc-4f8b-9751-24d2c2e80697@linux.ibm.com>","References":"<53f26493-09fc-4f8b-9751-24d2c2e80697@linux.ibm.com>","MIME-Version":"1.0","X-Spam-Status":"No, score=0.1 required=7.0 tests=DKIM_SIGNED,DKIM_VALID,\n DKIM_VALID_AU,DKIM_VALID_EF,DMARC_PASS,FREEMAIL_FROM,SPF_HELO_NONE,\n SPF_PASS shortcircuit=no autolearn=disabled version=4.0.1","X-Spam-Checker-Version":"SpamAssassin 4.0.1 (2024-03-25) on in-2.smtp.seeweb.it","X-Virus-Scanned":"clamav-milter 1.0.9 at in-2.smtp.seeweb.it","X-Virus-Status":"Clean","Subject":"Re: [LTP] sched_football: fix false failures on many-CPU systems","X-BeenThere":"ltp@lists.linux.it","X-Mailman-Version":"2.1.29","Precedence":"list","List-Id":"Linux Test Project ","List-Unsubscribe":",\n ","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n ","Cc":"ltp@lists.linux.it","Content-Type":"text/plain; charset=\"utf-8\"","Content-Transfer-Encoding":"base64","Errors-To":"ltp-bounces+incoming=patchwork.ozlabs.org@lists.linux.it","Sender":"\"ltp\" "}},{"id":3677568,"web_url":"http://patchwork.ozlabs.org/comment/3677568/","msgid":"","list_archive_url":null,"date":"2026-04-15T09:52:11","subject":"Re: [LTP] [PATCH] sched_football: fix false failures on many-CPU\n systems","submitter":{"id":74427,"url":"http://patchwork.ozlabs.org/api/people/74427/","name":"Li Wang","email":"wangli.ahau@gmail.com"},"content":"Hi Soma and Jan,\n\n> > 1. RT throttling freezes all SCHED_FIFO threads simultaneously. On\n> > release, the kernel does not always reschedule the highest-priority\n> > thread first on every CPU, so offense briefly runs and increments\n> > the_ball before defense is rescheduled. Fix by saving and disabling\n> > sched_rt_runtime_us in setup and restoring it in a new cleanup\n> > callback.\n\nMake sense, and like the AI-reviewer points out LTP provides an option\nto save_restore it automatically.\n\n> > 2. Offense and defense threads were unpinned, allowing the scheduler\n> > to migrate them freely. An offense thread could land on a CPU with\n> > no defense thread present and run unchecked. Fix by passing a CPU\n> > index as the thread arg and calling sched_setaffinity() at thread\n> > start. Pairs are distributed round-robin (i % ncpus) so each\n> > offense thread shares its CPU with a defense thread.\n\nThis is a good thought, as for SCHED_FIFO it manages the corresponding\nrunqueue for each CPU and simply picks the higher priority task to run.\nSo pinning the threads to each CPU makes sense, but maybe we could\nonly pin the defense because:\n\nWith N defense threads pinned one per CPU, every CPU has a defense\nthread at priority 30 permanently runnable. The offense threads at priority\n15, regardless of which CPU the scheduler places them on, will always find\na higher-priority defense thread on the same CPU's runqueue. Since\nSCHED_FIFO strictly favors the higher-priority runnable task, offense can\nnever be picked.\n\nPinning offense as well would be redundant, it doesn't matter where offense\nlands, because defense already covers every CPU. This also has the advantage\nof letting the scheduler freely migrate offense threads without\naffecting the test\noutcome, which avoids interfering with the kernel's load balancing logic during\nthe test.\n\nAnd, I'd suggest using tst_ncpus_available() instead of get_numcpus()\nwhen distributing defense threads across CPUs, in case some CPUs are\noffline. Pinning a defense thread to an offline CPU would leave that\nCPU uncovered and allow offense to run unchecked. See:\n\nAlso, the short usleep() after setting kickoff_flag, which was originally\nthere to give the RT load balancer time to distribute threads across CPUs,\ncan now be removed, since defense is already pinned to every CPU and\ncoverage is guaranteed without any extra settling time.\n\n- if (tst_check_preempt_rt())\n- usleep(20000);\n- else\n- usleep(2000000);\n\n\n> > 3. game_over was never reset between iterations, causing all threads\n> > to exit immediately on reruns (-i N), making the test a no-op.\n> > Fix by resetting both kickoff_flag and game_over at the top of\n> > do_test().\n\nGood catch.\n\n> > 4. sched_setscheduler() failure for the referee was silently ignored.\n> > If the call fails the test produces meaningless results. Fix by\n> > checking the return value and calling tst_brk(TBROK) on failure.\n\n+1\n\n> Tested-by: Jan Polensky \n\nThanks, can you re-test it based on what my above revision suggests?\n\n--\nRegards,\nLi Wang","headers":{"Return-Path":"","X-Original-To":["incoming@patchwork.ozlabs.org","ltp@lists.linux.it"],"Delivered-To":["patchwork-incoming@legolas.ozlabs.org","ltp@picard.linux.it"],"Authentication-Results":["legolas.ozlabs.org;\n\tdkim=fail reason=\"signature verification failed\" (2048-bit key;\n unprotected) header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256\n header.s=20251104 header.b=svTXSJfD;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=lists.linux.it\n (client-ip=2001:1418:10:5::2; helo=picard.linux.it;\n envelope-from=ltp-bounces+incoming=patchwork.ozlabs.org@lists.linux.it;\n receiver=patchwork.ozlabs.org)"],"Received":["from picard.linux.it (picard.linux.it [IPv6:2001:1418:10:5::2])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange x25519 server-signature ECDSA (secp384r1) server-digest SHA384)\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4fwbzN0kmkz1yCv\n\tfor ; Wed, 15 Apr 2026 19:52:32 +1000 (AEST)","from picard.linux.it (localhost [IPv6:::1])\n\tby picard.linux.it (Postfix) with ESMTP id C66123E5B68\n\tfor ; Wed, 15 Apr 2026 11:52:29 +0200 (CEST)","from in-3.smtp.seeweb.it (in-3.smtp.seeweb.it\n [IPv6:2001:4b78:1:20::3])\n (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n key-exchange X25519 server-signature ECDSA (secp384r1))\n (No client certificate requested)\n by picard.linux.it (Postfix) with ESMTPS id DDCC93E2660\n for ; Wed, 15 Apr 2026 11:52:25 +0200 (CEST)","from mail-qt1-x835.google.com (mail-qt1-x835.google.com\n [IPv6:2607:f8b0:4864:20::835])\n (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)\n key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest\n SHA256)\n (No client certificate requested)\n by in-3.smtp.seeweb.it (Postfix) with ESMTPS id 3C8F01A007ED\n for ; Wed, 15 Apr 2026 11:52:25 +0200 (CEST)","by mail-qt1-x835.google.com with SMTP id\n d75a77b69052e-50b2b289925so54164341cf.2\n for ; Wed, 15 Apr 2026 02:52:25 -0700 (PDT)"],"ARC-Seal":"i=1; a=rsa-sha256; t=1776246744; cv=none;\n d=google.com; s=arc-20240605;\n b=P/xoTxA8GQE24hNkiL/C1J7h04ptsfSqLj25yxAHRFE/6wTKtaC8IDJ+F1SvsCXrsU\n DB8Kd1EFlCL0RfZZRwvGXP2TLYAR+hwKSZkUj8st3bAPySbP32Ng/SykA//2nB2VenQQ\n n6ITWfEVIlcw3WggH6mAV9/hPg9fTc6SgcQV3YDcRHJGk8nc/at76ac+Joe9M5D/b/qN\n YjyJDTDEK3EF348lk5cnV5LdAIqRSAOOm1qtsGGBh1UXY7Wfw8rioW1sMoEv3oIceqoQ\n rVXviR8ovS7wPmvJ9tTsiWH5YW3PzT+X+z+2AmzcYcLg542YkNnucpfqsc9iB/2fioy4\n U2Zw==","ARC-Message-Signature":"i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com;\n s=arc-20240605;\n h=cc:to:subject:message-id:date:from:in-reply-to:references\n :mime-version:dkim-signature;\n bh=4dWWC9FqxS+TqVlI0Oe27UQtL/Cucw8jGow8hZc1jjk=;\n fh=iiQDWzqcvLqJlWA25u3IRlJ3QztPU47SwJAHJLx1g20=;\n b=lIXU/FJKdyG4KFm8wEyGGA+CY+YT0UhP6GNXwhkhplmr1R5hxWUGBn0TlZX7gv5Gkf\n 1rWS7ybozLQMDT8teYBNTKOSWtEnepOFipsHEg9BbKDeY3h+yL53T2ClHHMVC2+fzJzI\n Y+ev3Cd0rr8G5JtncsadAKCEDYbRbaubM9YCEHHSKNF9RfGXZ/1ftCsuZd6oJIGl8LRi\n RgHEcMFMQieRXu+OqnyogLSUIv37bz+UECmPVE9Vf8srHfkp05AP6S1uol4KPziEbPdE\n eOR7BtLQ6U/G2Pv1v3kcLcW3+C6ScuTyhXvouDw3b/9fcWxkHvHFf65MI6WV1/k9QNq7\n iBHA==; darn=lists.linux.it","ARC-Authentication-Results":"i=1; mx.google.com; arc=none","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n d=gmail.com; s=20251104; t=1776246744; x=1776851544; darn=lists.linux.it;\n h=cc:to:subject:message-id:date:from:in-reply-to:references\n :mime-version:from:to:cc:subject:date:message-id:reply-to;\n bh=4dWWC9FqxS+TqVlI0Oe27UQtL/Cucw8jGow8hZc1jjk=;\n b=svTXSJfD6dxOcgeupQOjae7Lb4TilqNmlJEtMmdT2tlip1moj4rJmDxtvPndWYcSWa\n 1D1pYzxPOeFIdE3XvnPQNNqSVS0sOhMq5Lhv2P4yiKc9En2Hbv9KKNonaq7mnO1yZRi4\n UMs3FViBloNHtQ3JzZiZxMCg5mvL1yo2S5AfkZtP85BOEPfxTqCqSyPpB5916x8DzJWv\n v+dIycV6ErzaN0zsDRTfUPPyYNyJhw8NMKLjN97znktwFDXsv1DUn71x9ZPrssFxqJtb\n gH1/MJ4eOchMKTI+OBUx80uDGvE0iHxd6kHJLMY4jibqNeogJHRaboodM23THlI+Rtn4\n mjsg==","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n d=1e100.net; s=20251104; t=1776246744; x=1776851544;\n h=cc:to:subject:message-id:date:from:in-reply-to:references\n :mime-version:x-gm-gg:x-gm-message-state:from:to:cc:subject:date\n :message-id:reply-to;\n bh=4dWWC9FqxS+TqVlI0Oe27UQtL/Cucw8jGow8hZc1jjk=;\n b=UmCooSdCFkf/8NtFgZVM0e70okHhRLu6WU+NePhse8LCjY0Ml1XzclhUPf5wh65qzf\n O/IC82tvQniMvYNIp7nnSPEZ2WXyqxfPH6aWwbsgSj+B3M96yy3mbJfElksPT2mBy7Cs\n BmT+ArIV6p2Rk/PwTE3i5YiG/YqUQtZTOsiT3zmIxKpv3fXeRElK5NYhXE/vTL+c2CsV\n y3UuqjmerfwQQUZPEUV8D9UEss2ivARpLl78TKKlG0WDNgDHGezQLqY0U1k88sCk6Ncx\n f4jEF6ohFosrti6yPtgW1CRDduC1dqCMXQkf/TJZ9Wzpzivhjn2wfcoaQz1RYCuqTNZ7\n g/2w==","X-Gm-Message-State":"AOJu0YyRMO48tsSNia1cpOPPH/asNQb0pKj2Zu+oNbbuHIwdixRpr+ap\n mcdaE1T3rlaCMQnIBN6xkWLBGlyPdIjjZ1gQ7Sn8/UeEIjwsYjEUePmS4uV47NqoDhs0RcBykif\n Q7mEdoR2XciMy3YbSC1KDSHN2m67ToQ==","X-Gm-Gg":"AeBDies7AAQq3TzL4I4C8/WZqqh+Pr3P5QtZeUxvC86AOsKc+qYJwyc9Mcq+bZPpyad\n 5AqpKPWceJy+br1jBLeRQZecrYg4Ztah1i5zJLUl3KCNYf8d8zyokFar/jb7P0J5j6XNvToUXeG\n h463hV4iMN9hzWRv3pIdpuI8WcRQXNDcpVohQ4Ek0ALjKpbZT8FnhbjdhhnbR8a6FOadfM3e3pJ\n 4eOsVGTYO56zrtTuCBrbmT8ojRrobKgUkC8FPaBKHU/s30e3bmBQ1kUGk6xI6/bdjmhHDBpCeLC\n AJV0JP+ap9ORHvhRQ6JG5RRRN9A=","X-Received":"by 2002:a05:622a:550d:b0:50b:3788:ab58 with SMTP id\n d75a77b69052e-50dd5acb1e9mr312275481cf.17.1776246743874; Wed, 15 Apr 2026\n 02:52:23 -0700 (PDT)","MIME-Version":"1.0","References":"<53f26493-09fc-4f8b-9751-24d2c2e80697@linux.ibm.com>\n ","In-Reply-To":"\n ","From":"Li Wang ","Date":"Wed, 15 Apr 2026 17:52:11 +0800","X-Gm-Features":"AQROBzBUc-qadwFkgR-JCscazqHWDGakCZzA4gS-a2_MLgKbcLjKPBZI2HPeioo","Message-ID":"\n ","To":"Jan Polensky , Soma Das ","X-Spam-Status":"No, score=0.1 required=7.0 tests=DKIM_SIGNED,DKIM_VALID,\n DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,SPF_HELO_NONE,SPF_PASS\n shortcircuit=no autolearn=disabled version=4.0.1","X-Spam-Checker-Version":"SpamAssassin 4.0.1 (2024-03-25) on in-3.smtp.seeweb.it","X-Virus-Scanned":"clamav-milter 1.0.9 at in-3.smtp.seeweb.it","X-Virus-Status":"Clean","Subject":"Re: [LTP] [PATCH] sched_football: fix false failures on many-CPU\n systems","X-BeenThere":"ltp@lists.linux.it","X-Mailman-Version":"2.1.29","Precedence":"list","List-Id":"Linux Test Project ","List-Unsubscribe":",\n ","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n ","Cc":"jstultz@google.com, ltp@lists.linux.it","Content-Type":"text/plain; charset=\"us-ascii\"","Content-Transfer-Encoding":"7bit","Errors-To":"ltp-bounces+incoming=patchwork.ozlabs.org@lists.linux.it","Sender":"\"ltp\" "}},{"id":3677728,"web_url":"http://patchwork.ozlabs.org/comment/3677728/","msgid":"","list_archive_url":null,"date":"2026-04-15T15:20:08","subject":"Re: [LTP] [PATCH] sched_football: fix false failures on many-CPU\n systems","submitter":{"id":90848,"url":"http://patchwork.ozlabs.org/api/people/90848/","name":"Jan Polensky","email":"japo@linux.ibm.com"},"content":"On Wed, Apr 15, 2026 at 05:52:11PM +0800, Li Wang wrote:\n> Hi Soma and Jan,\n>\n> > > 1. RT throttling freezes all SCHED_FIFO threads simultaneously. On\n> > > release, the kernel does not always reschedule the highest-priority\n> > > thread first on every CPU, so offense briefly runs and increments\n> > > the_ball before defense is rescheduled. Fix by saving and disabling\n> > > sched_rt_runtime_us in setup and restoring it in a new cleanup\n> > > callback.\n>\n> Make sense, and like the AI-reviewer points out LTP provides an option\n> to save_restore it automatically.\n>\n> > > 2. Offense and defense threads were unpinned, allowing the scheduler\n> > > to migrate them freely. An offense thread could land on a CPU with\n> > > no defense thread present and run unchecked. Fix by passing a CPU\n> > > index as the thread arg and calling sched_setaffinity() at thread\n> > > start. Pairs are distributed round-robin (i % ncpus) so each\n> > > offense thread shares its CPU with a defense thread.\n>\n> This is a good thought, as for SCHED_FIFO it manages the corresponding\n> runqueue for each CPU and simply picks the higher priority task to run.\n> So pinning the threads to each CPU makes sense, but maybe we could\n> only pin the defense because:\n>\n> With N defense threads pinned one per CPU, every CPU has a defense\n> thread at priority 30 permanently runnable. The offense threads at priority\n> 15, regardless of which CPU the scheduler places them on, will always find\n> a higher-priority defense thread on the same CPU's runqueue. Since\n> SCHED_FIFO strictly favors the higher-priority runnable task, offense can\n> never be picked.\n>\n> Pinning offense as well would be redundant, it doesn't matter where offense\n> lands, because defense already covers every CPU. This also has the advantage\n> of letting the scheduler freely migrate offense threads without\n> affecting the test\n> outcome, which avoids interfering with the kernel's load balancing logic during\n> the test.\n>\n> And, I'd suggest using tst_ncpus_available() instead of get_numcpus()\n> when distributing defense threads across CPUs, in case some CPUs are\n> offline. Pinning a defense thread to an offline CPU would leave that\n> CPU uncovered and allow offense to run unchecked. See:\n>\n> Also, the short usleep() after setting kickoff_flag, which was originally\n> there to give the RT load balancer time to distribute threads across CPUs,\n> can now be removed, since defense is already pinned to every CPU and\n> coverage is guaranteed without any extra settling time.\n>\n> - if (tst_check_preempt_rt())\n> - usleep(20000);\n> - else\n> - usleep(2000000);\n>\n>\n> > > 3. game_over was never reset between iterations, causing all threads\n> > > to exit immediately on reruns (-i N), making the test a no-op.\n> > > Fix by resetting both kickoff_flag and game_over at the top of\n> > > do_test().\n>\n> Good catch.\n>\n> > > 4. sched_setscheduler() failure for the referee was silently ignored.\n> > > If the call fails the test produces meaningless results. Fix by\n> > > checking the return value and calling tst_brk(TBROK) on failure.\n>\n> +1\n>\n> > Tested-by: Jan Polensky \n>\n> Thanks, can you re-test it based on what my above revision suggests?\n>\n> --\n> Regards,\n> Li Wang\n\nHi Li, hi Soma,\n\n@Li: I incorporated your suggested changes and re-tested. Works fine for\nme on the same machine as before.\n\n\t./sched_football -i 10\n [snip]\n Summary:\n passed 10\n failed 0\n broken 0\n skipped 0\n warnings 0\n\nTested-by: Jan Polensky \n\n@Soma: Feel free to pick it up, the diff/patch is attached below.\nPlease note the additional join_threads() call, it is needed if you run the test like:\n\n\t./sched_football -i 10\n\nIt seems the threads do not terminate correctly without it.\n\ndiff --git a/testcases/realtime/func/sched_football/sched_football.c b/testcases/realtime/func/sched_football/sched_football.c\nindex 43bac9468693..be0334da812e 100644\n--- a/testcases/realtime/func/sched_football/sched_football.c\n+++ b/testcases/realtime/func/sched_football/sched_football.c\n@@ -118,23 +118,17 @@ void *thread_defense(void *arg)\n }\n\n /* This is the offensive team. They're trying to move the ball */\n-void *thread_offense(void *arg)\n+void *thread_offense(void *arg LTP_ATTRIBUTE_UNUSED)\n {\n-\tstruct thread *t = (struct thread *)arg;\n-\tint cpu = (int)(intptr_t)t->arg;\n-\tcpu_set_t cpuset;\n-\n \tprctl(PR_SET_NAME, \"offense\", 0, 0, 0);\n\n \t/*\n-\t * Pin to the same CPU as the paired defense thread so there is\n-\t * always a higher-priority defense thread locally available to\n-\t * preempt this one without requiring cross-CPU migration.\n+\t * Offense threads are not pinned. With defense threads pinned one per\n+\t * CPU at priority 30, every CPU has a higher-priority defense thread\n+\t * runnable. Offense at priority 15 can never be picked by SCHED_FIFO\n+\t * regardless of which CPU it lands on. Leaving offense unpinned avoids\n+\t * interfering with the kernel's load balancing logic.\n \t */\n-\tCPU_ZERO(&cpuset);\n-\tCPU_SET(cpu, &cpuset);\n-\tif (sched_setaffinity(0, sizeof(cpuset), &cpuset) != 0)\n-\t\ttst_brk(TBROK | TERRNO, \"sched_setaffinity failed for offense on CPU %d\", cpu);\n\n \tpthread_barrier_wait(&start_barrier);\n \twhile (!tst_atomic_load(&kickoff_flag))\n@@ -169,10 +163,6 @@ void referee(int game_length)\n\n \ttst_atomic_store(0, &the_ball);\n \ttst_atomic_store(1, &kickoff_flag);\n-\tif (tst_check_preempt_rt())\n-\t\tusleep(20000);\n-\telse\n-\t\tusleep(2000000);\n\n \t/* Watch the game */\n \twhile ((now.tv_sec - start.tv_sec) < game_length) {\n@@ -199,10 +189,10 @@ static void do_test(void)\n \tint i;\n\n \tif (players_per_team == 0)\n-\t\tplayers_per_team = get_numcpus();\n+\t\tplayers_per_team = tst_ncpus_available();\n\n \t/* actual CPU count used for affinity assignment, independent of players_per_team */\n-\tncpus = get_numcpus();\n+\tncpus = tst_ncpus_available();\n\n \ttst_res(TINFO, \"players_per_team: %d game_length: %d\",\n \t players_per_team, game_length);\n@@ -227,10 +217,8 @@ static void do_test(void)\n \tpriority = 15;\n \ttst_res(TINFO, \"Starting %d offense threads at priority %d\",\n \t players_per_team, priority);\n-\t/* i % ncpus distributes threads round-robin across CPUs; the CPU index is\n-\t * passed as the thread arg so offense and defense pairs share the same CPU */\n \tfor (i = 0; i < players_per_team; i++)\n-\t\tcreate_fifo_thread(thread_offense, (void *)(intptr_t)(i % ncpus), priority);\n+\t\tcreate_fifo_thread(thread_offense, NULL, priority);\n\n \t/* Start the defense */\n \tpriority = 30;\n@@ -248,6 +236,7 @@ static void do_test(void)\n\n \treferee(game_length);\n\n+\tjoin_threads();\n \tpthread_barrier_destroy(&start_barrier);\n }","headers":{"Return-Path":"","X-Original-To":["incoming@patchwork.ozlabs.org","ltp@lists.linux.it"],"Delivered-To":["patchwork-incoming@legolas.ozlabs.org","ltp@picard.linux.it"],"Authentication-Results":["legolas.ozlabs.org;\n\tdkim=fail reason=\"signature verification failed\" (2048-bit key;\n unprotected) header.d=ibm.com header.i=@ibm.com header.a=rsa-sha256\n header.s=pp1 header.b=YB6Gq5Av;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=lists.linux.it\n (client-ip=2001:1418:10:5::2; helo=picard.linux.it;\n envelope-from=ltp-bounces+incoming=patchwork.ozlabs.org@lists.linux.it;\n receiver=patchwork.ozlabs.org)"],"Received":["from picard.linux.it (picard.linux.it [IPv6:2001:1418:10:5::2])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange x25519 server-signature ECDSA (secp384r1) server-digest SHA384)\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4fwlFg1tCsz1yHc\n\tfor ; Thu, 16 Apr 2026 01:20:23 +1000 (AEST)","from picard.linux.it (localhost [IPv6:::1])\n\tby picard.linux.it (Postfix) with ESMTP id 2EF3B3E71EE\n\tfor ; Wed, 15 Apr 2026 17:20:20 +0200 (CEST)","from in-7.smtp.seeweb.it (in-7.smtp.seeweb.it [217.194.8.7])\n (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n key-exchange X25519 server-signature ECDSA (secp384r1))\n (No client certificate requested)\n by picard.linux.it (Postfix) with ESMTPS id 1C15E3E5BB2\n for ; Wed, 15 Apr 2026 17:20:16 +0200 (CEST)","from mx0a-001b2d01.pphosted.com (mx0a-001b2d01.pphosted.com\n [148.163.156.1])\n (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest\n SHA256)\n (No client certificate requested)\n by in-7.smtp.seeweb.it (Postfix) with ESMTPS id 0FF872001A7\n for ; Wed, 15 Apr 2026 17:20:14 +0200 (CEST)","from pps.filterd (m0356517.ppops.net [127.0.0.1])\n by mx0a-001b2d01.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id\n 63FDF4mR1832986; Wed, 15 Apr 2026 15:20:13 GMT","from ppma13.dal12v.mail.ibm.com\n (dd.9e.1632.ip4.static.sl-reverse.com [50.22.158.221])\n by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 4dh89rgtm0-1\n (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT);\n Wed, 15 Apr 2026 15:20:12 +0000 (GMT)","from pps.filterd (ppma13.dal12v.mail.ibm.com [127.0.0.1])\n by ppma13.dal12v.mail.ibm.com (8.18.1.2/8.18.1.2) with ESMTP id\n 63FDt2tE025643;\n Wed, 15 Apr 2026 15:20:11 GMT","from smtprelay04.fra02v.mail.ibm.com ([9.218.2.228])\n by ppma13.dal12v.mail.ibm.com (PPS) with ESMTPS id 4dg2ujpkd1-1\n (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT);\n Wed, 15 Apr 2026 15:20:11 +0000","from smtpav06.fra02v.mail.ibm.com (smtpav06.fra02v.mail.ibm.com\n [10.20.54.105])\n by smtprelay04.fra02v.mail.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id\n 63FFKARQ26870518\n (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);\n Wed, 15 Apr 2026 15:20:10 GMT","from smtpav06.fra02v.mail.ibm.com (unknown [127.0.0.1])\n by IMSVA (Postfix) with ESMTP id 11FE120049;\n Wed, 15 Apr 2026 15:20:10 +0000 (GMT)","from smtpav06.fra02v.mail.ibm.com (unknown [127.0.0.1])\n by IMSVA (Postfix) with ESMTP id E41FB20040;\n Wed, 15 Apr 2026 15:20:09 +0000 (GMT)","from li-276bd24c-2dcc-11b2-a85c-945b6f05615c.ibm.com (unknown\n [9.52.197.53]) by smtpav06.fra02v.mail.ibm.com (Postfix) with ESMTPS;\n Wed, 15 Apr 2026 15:20:09 +0000 (GMT)"],"DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed; d=ibm.com; h=cc\n :content-type:date:from:in-reply-to:message-id:mime-version\n :references:subject:to; s=pp1; bh=Af01ivoeuYFqSYJayCOFLzVYnU73OQ\n T+qO+B8PcBH38=; b=YB6Gq5AvQBWDXNe3WXn+YYqupUwTLj3iLue76HorY3+yCl\n 0FECmFs1Q4AjvKsjbKN0LqKpR15tYL4awyCSCjFfkrpjLi6AKusl755hzrq2kJHS\n AoiwAN3H/TEbozBMhh2ZwsfPqnaHNedSX52kk4Iv4SN6snVQtmgrqI2KsrrzBdpz\n Ze3nnsIhcKeyiev8hQACsycmKTJtfUvNIL4GgmXZxhfM4W13XQzxvdHQe9pgCO4D\n Y5kBiDtdbrBkvpw+jls5bFMhci42M36pkd71i3l2m4sddl8DdZ+3hibfwWyXdEP4\n jglKTdAOWqLP3rhUEJObNMETJYP2vofTbhjNSSIw==","Date":"Wed, 15 Apr 2026 17:20:08 +0200","From":"Jan Polensky ","To":"Li Wang , Soma Das ","Message-ID":"","References":"<53f26493-09fc-4f8b-9751-24d2c2e80697@linux.ibm.com>\n \n ","MIME-Version":"1.0","Content-Disposition":"inline","In-Reply-To":"\n ","X-TM-AS-GCONF":"00","X-Proofpoint-Reinject":"loops=2 maxloops=12","X-Proofpoint-Spam-Details-Enc":"AW1haW4tMjYwNDE1MDE0MiBTYWx0ZWRfX4IN9oEcS/bD7\n +3PJT4LwtMMf0wj25UOD39ycyXJzmqSOS3mm0Q3U6yETsbvgF3m/IVlzj3hn3aJr8qNRvsQvzz9\n wfkiZE9WbT8sQ0rVscaj10Sy8vFNUPwPwvKJlwXKPANHTra4rAZLAQPM4lFANhXa7RyHSGgCQUV\n dSrgpLbx+mBIC8bD9Euwxu9/5Iuvt5VQDYR3AefnduSbmA31bHrzoieUxPDXTB0R0QN5nW3/Deg\n SHUM/sAXHKF70ijBB/Mb/SMJFGtN6HyBiKJB9e7nyg8cCx7WBdwK72J7btkuhj9U8CsuwdLCjmk\n u2RNg6soeMIfbG+h5Rj1I2GSWTJ+O3sDLemHunNbZrNrOOBya9vd8x2571qjgFsn34mMluQEDAU\n /RD6P1jdO41qjebo9V8scqk880F8OKUxugy+LZf+E4GoHGIHUoSqThAoABNe+Rrljn7CZMfzinp\n 8j5E1pNDTVejOIlpQbg==","X-Proofpoint-ORIG-GUID":"FmOAEovk6aA4xJ9z3cuDbby8_Ol1LBpa","X-Proofpoint-GUID":"SDTjYoCJFVmD1z3H8yWtHaNBPRGIRZ5F","X-Authority-Analysis":"v=2.4 cv=fYidDUQF c=1 sm=1 tr=0 ts=69dfacac cx=c_pps\n a=AfN7/Ok6k8XGzOShvHwTGQ==:117 a=AfN7/Ok6k8XGzOShvHwTGQ==:17\n a=kj9zAlcOel0A:10 a=A5OVakUREuEA:10 a=VkNPw1HP01LnGYTKEx00:22\n a=RnoormkPH1_aCDwRdu11:22 a=U7nrCbtTmkRpXpFmAIza:22 a=VnNF1IyMAAAA:8\n a=svtOvR90bENhbL-BqmcA:9 a=CjuIK1q_8ugA:10","X-Proofpoint-Virus-Version":"vendor=baseguard\n engine=ICAP:2.0.293,Aquarius:18.0.1143,Hydra:6.1.51,FMLib:17.12.100.49\n definitions=2026-04-15_01,2026-04-13_04,2025-10-01_01","X-Proofpoint-Spam-Details":"rule=outbound_notspam policy=outbound score=0\n adultscore=0 impostorscore=0 clxscore=1015 malwarescore=0 phishscore=0\n bulkscore=0 priorityscore=1501 spamscore=0 suspectscore=0 lowpriorityscore=0\n classifier=typeunknown authscore=0 authtc= authcc= route=outbound adjust=0\n reason=mlx scancount=1 engine=8.22.0-2604070000 definitions=main-2604150142","X-Spam-Status":"No, score=0.1 required=7.0 tests=DKIM_SIGNED,DKIM_VALID,\n SPF_HELO_NONE,SPF_PASS shortcircuit=no autolearn=disabled version=4.0.1","X-Spam-Checker-Version":"SpamAssassin 4.0.1 (2024-03-25) on in-7.smtp.seeweb.it","X-Virus-Scanned":"clamav-milter 1.0.9 at in-7.smtp.seeweb.it","X-Virus-Status":"Clean","Subject":"Re: [LTP] [PATCH] sched_football: fix false failures on many-CPU\n systems","X-BeenThere":"ltp@lists.linux.it","X-Mailman-Version":"2.1.29","Precedence":"list","List-Id":"Linux Test Project ","List-Unsubscribe":",\n ","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n ","Cc":"jstultz@google.com, ltp@lists.linux.it","Content-Type":"text/plain; charset=\"us-ascii\"","Content-Transfer-Encoding":"7bit","Errors-To":"ltp-bounces+incoming=patchwork.ozlabs.org@lists.linux.it","Sender":"\"ltp\" "}},{"id":3677809,"web_url":"http://patchwork.ozlabs.org/comment/3677809/","msgid":"","list_archive_url":null,"date":"2026-04-15T20:21:02","subject":"Re: [LTP] [PATCH] sched_football: fix false failures on many-CPU\n systems","submitter":{"id":85767,"url":"http://patchwork.ozlabs.org/api/people/85767/","name":"John Stultz","email":"jstultz@google.com"},"content":"On Wed, Apr 15, 2026 at 8:20 AM Jan Polensky wrote:\n> On Wed, Apr 15, 2026 at 05:52:11PM +0800, Li Wang wrote:\n> > Hi Soma and Jan,\n> >\n> > > > 1. RT throttling freezes all SCHED_FIFO threads simultaneously. On\n> > > > release, the kernel does not always reschedule the highest-priority\n> > > > thread first on every CPU, so offense briefly runs and increments\n> > > > the_ball before defense is rescheduled. Fix by saving and disabling\n> > > > sched_rt_runtime_us in setup and restoring it in a new cleanup\n> > > > callback.\n> >\n> > Make sense, and like the AI-reviewer points out LTP provides an option\n> > to save_restore it automatically.\n\nThrottling shouldn't break the test. The fact that SCHED_NORMAL tasks\nran shouldn't change the ordering when we go back to running RT tasks.\nThis is likely a kernel bug.\n\n> > > > 2. Offense and defense threads were unpinned, allowing the scheduler\n> > > > to migrate them freely. An offense thread could land on a CPU with\n> > > > no defense thread present and run unchecked. Fix by passing a CPU\n> > > > index as the thread arg and calling sched_setaffinity() at thread\n> > > > start. Pairs are distributed round-robin (i % ncpus) so each\n> > > > offense thread shares its CPU with a defense thread.\n> >\n> > This is a good thought, as for SCHED_FIFO it manages the corresponding\n> > runqueue for each CPU and simply picks the higher priority task to run.\n> > So pinning the threads to each CPU makes sense, but maybe we could\n> > only pin the defense because:\n> >\n> > With N defense threads pinned one per CPU, every CPU has a defense\n> > thread at priority 30 permanently runnable. The offense threads at priority\n> > 15, regardless of which CPU the scheduler places them on, will always find\n> > a higher-priority defense thread on the same CPU's runqueue. Since\n> > SCHED_FIFO strictly favors the higher-priority runnable task, offense can\n> > never be picked.\n> >\n> > Pinning offense as well would be redundant, it doesn't matter where offense\n> > lands, because defense already covers every CPU. This also has the advantage\n> > of letting the scheduler freely migrate offense threads without\n> > affecting the test\n> > outcome, which avoids interfering with the kernel's load balancing logic during\n> > the test.\n> >\n> > And, I'd suggest using tst_ncpus_available() instead of get_numcpus()\n> > when distributing defense threads across CPUs, in case some CPUs are\n> > offline. Pinning a defense thread to an offline CPU would leave that\n> > CPU uncovered and allow offense to run unchecked. See:\n\nI didn't see the orignal patch here, but the whole point of\nsched_football is to ensure the top (unaffined) priority\ntasks are always run and no lower priority rt tasks are run instead.\n\nSo none of the tasks should be pinned to any cpus. The scheduler is\nsupposed to ensure the RT invariant holds.\nThere are some known bugs at the moment that will cause sched_football\nto fail (the RT_PUSH_IPI feature, for instance). That's a problem with\nthe kernel, not the test.\n\nthanks\n-john","headers":{"Return-Path":"","X-Original-To":["incoming@patchwork.ozlabs.org","ltp@lists.linux.it"],"Delivered-To":["patchwork-incoming@legolas.ozlabs.org","ltp@picard.linux.it"],"Authentication-Results":["legolas.ozlabs.org;\n\tdkim=pass (1024-bit key;\n unprotected) header.d=lists.linux.it header.i=@lists.linux.it\n header.a=rsa-sha256 header.s=picard header.b=BSg5b75v;\n\tdkim=fail reason=\"signature verification failed\" (2048-bit key;\n unprotected) header.d=google.com header.i=@google.com header.a=rsa-sha256\n header.s=20251104 header.b=ELo0BABY;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=lists.linux.it\n (client-ip=213.254.12.146; helo=picard.linux.it;\n envelope-from=ltp-bounces+incoming=patchwork.ozlabs.org@lists.linux.it;\n receiver=patchwork.ozlabs.org)"],"Received":["from picard.linux.it (picard.linux.it [213.254.12.146])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange x25519 server-signature ECDSA (secp384r1) server-digest SHA384)\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4fwsx53GlFz1yHc\n\tfor ; Thu, 16 Apr 2026 06:21:27 +1000 (AEST)","from picard.linux.it (localhost [IPv6:::1])\n\tby picard.linux.it (Postfix) with ESMTP id 54C443E2681\n\tfor ; Wed, 15 Apr 2026 22:21:22 +0200 (CEST)","from in-3.smtp.seeweb.it (in-3.smtp.seeweb.it [217.194.8.3])\n (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n key-exchange X25519 server-signature ECDSA (secp384r1))\n (No client certificate requested)\n by picard.linux.it (Postfix) with ESMTPS id 890893CB6BF\n for ; Wed, 15 Apr 2026 22:21:17 +0200 (CEST)","from mail-ua1-x92e.google.com (mail-ua1-x92e.google.com\n [IPv6:2607:f8b0:4864:20::92e])\n (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)\n key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest\n SHA256)\n (No client certificate requested)\n by in-3.smtp.seeweb.it (Postfix) with ESMTPS id 17E571A00264\n for ; Wed, 15 Apr 2026 22:21:17 +0200 (CEST)","by mail-ua1-x92e.google.com with SMTP id\n a1e0cc1a2514c-95699e8e26aso893540241.0\n for ; Wed, 15 Apr 2026 13:21:17 -0700 (PDT)"],"DKIM-Signature":["v=1; a=rsa-sha256; c=relaxed/simple; d=lists.linux.it;\n i=@lists.linux.it; q=dns/txt; s=picard; t=1776284482; h=mime-version :\n references : in-reply-to : date : message-id : to : subject : list-id\n : list-unsubscribe : list-archive : list-post : list-help :\n list-subscribe : from : reply-to : cc : content-type :\n content-transfer-encoding : sender : from;\n bh=aOzN8O3IDj/djIvu58rZpuzhcRjP9QKMSsmpJvwPky0=;\n b=BSg5b75vy7Uf4yyscuSahwM2fdgPBBphZcRxBIAZ4MsBbocwlKoEoRowhN2zRR4Boykux\n O5m6Mz5RhFsoPlxENCjkeFffeBbeugD3rwieaf/kOgr6gUBFP3aZr9yQ/ptJ6jc9wtHiy7U\n sHG5pF62wWbhcMCn++88f/uQO0NxbCc=","v=1; a=rsa-sha256; c=relaxed/relaxed;\n d=google.com; s=20251104; t=1776284476; x=1776889276; darn=lists.linux.it;\n h=content-transfer-encoding:cc:to:subject:message-id:date:from\n :in-reply-to:references:mime-version:from:to:cc:subject:date\n :message-id:reply-to;\n bh=lMeaEhX6NCDliM3JhdR1douUBFEeUzEBllgQHTNp2YI=;\n b=ELo0BABYWS4wYRlyV5Fm5J3hcTHEDz0s1y9lKXTEeQqwiWq1V9HQzBh7BOw4e3R0IT\n JPGOVSiCNnlet6q+rUJYL1t0Pw6IakjM4RvfhYszPpBv5eKSLXqgQFdcEbKBGD4ehOjY\n bWO6MHaNziwE7nCfT1aeMjha0kn8ySfhU21qZRldg7UYIq2HogzxXfVDIwPY82BmHboH\n yuWTj1T8su+DZNgTd0XzMmOzb1QYvMgDt49n0aBAL67tXw6YEl7UQWYZzJOQLGgiCyDT\n blNd7Es07DhjiBIe+FGQWNJDGGWJKEW93ErhGIsxp8CQdy8F23/uGy62JGcWAcXrXusO\n dawA=="],"ARC-Seal":"i=1; a=rsa-sha256; t=1776284476; cv=none;\n d=google.com; s=arc-20240605;\n b=bMC7tJ637NhO3YQ8ncdKvVOSPU8k3OoLVTguHnA8gp1SHNPggt9OX+SsYssvKcLh+P\n wUcunzIAvXWyrBh9AcJr/lBJciY1zZbYFHfjhkqYYjhxQDGvkY6PfLyR/lv3WyknBP+i\n O74d/CjdqApVKUembu3ZgUrQNJmr60VFf/7huCROJad5PRKjypC+8hXuHDnyTPbiYcvv\n rwiBRbfCX/FiDtnJL8cs4lPin/myuKGjMwROdx8yRvQlkjv9tCnqqRU01wYnjV5OGevl\n JmHSzsFjV4b/RCycZMR9t7ZfgMyRxgSEWpJXmAjt/ZJrs30t+nNwq9beZxvbKyVboRsH\n PehA==","ARC-Message-Signature":"i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com;\n s=arc-20240605;\n h=content-transfer-encoding:cc:to:subject:message-id:date:from\n :in-reply-to:references:mime-version:dkim-signature;\n bh=lMeaEhX6NCDliM3JhdR1douUBFEeUzEBllgQHTNp2YI=;\n fh=DUtt9KdDPrd81V+i/AjmN59os3iUSXX3UNjUPI6ZE6w=;\n b=Bg29GWaRejIvtPq+w5+BM1r3omXOcKT+tbtNwHmByAaQMHH5Xxw8OgGbE13J8YGJ83\n HreSoEnAvjmTK3LoMQiNByuWRQSooCXsEy/oTDVQ9OUDBA7uuFuftPRnOSpB3QZrHUvj\n w2md9UxY05f6eKXXf7FFVxK5l3Xe7pY1KdzSQiC2Qr0plSoHb6HwIVaObwRzT4QN9JEQ\n GfDxkDgzALE60E44VwFiYyu5UFBOJQ49tERnlHWAigETGea1BK/njLQpWgH8RzoKe/9H\n wCK8OMcAT4Ptrx8gGgTkLX3mqjIdgv40Nme7/+d11imOuwLTSdEb0WKsWU7dYNw0WOHN\n k8cg==; darn=lists.linux.it","ARC-Authentication-Results":"i=1; mx.google.com; arc=none","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n d=1e100.net; s=20251104; t=1776284476; x=1776889276;\n h=content-transfer-encoding:cc:to:subject:message-id:date:from\n :in-reply-to:references:mime-version:x-gm-gg:x-gm-message-state:from\n :to:cc:subject:date:message-id:reply-to;\n bh=lMeaEhX6NCDliM3JhdR1douUBFEeUzEBllgQHTNp2YI=;\n b=Coaq8K+DzMK+/ud+1KVB9rj9lRhqU+AeCI7WFLqf9FDUNRuwok4zR2NAqQpwPkIVM/\n dvsElMKOLRvsF93EMgVpNZzsD1xu9s9VMBT0/yowNlYfzIKAM9DpBKXRHZHvyMyzvxBJ\n k8mRDzaVImJbirWzMY9TjMeDJ4y+zWTqMXsozM8t8+57vp1LIWtAJQjdWQT3LLm4XlnB\n wR/T2NrY04TSf3UhaFw0dW4JkRUjib8+VXXfUCw+6mNMMmaI51tT9fflGm5xCtMB/46N\n a9g+WZGXf5/z2tNQ/v+jWixoboWk++NQqu6Kw1VGTE4uTbfObwUsTz7X4lZQ3GgRbDf7\n UXdQ==","X-Forwarded-Encrypted":"i=1;\n AFNElJ/X3iDIJe0SreDSSjVk6w0XnkQ6WZTDUpK1/5EuEftt5fmgBTRqlsnQ3X+3gJokcy0y3AQ=@lists.linux.it","X-Gm-Message-State":"AOJu0YxNjjCaX4fREMiIMgFNrDTdfE2SaA2+GkvgaVelBQy3PvFqa06R\n CkkqpHbayWXq+ktsfZnjm451o6AQ3ZO609PM8ECoLlDopP9q7kIPhVUqxDKEybvWUnQxk5KA7p+\n XSS71HHYwKu6c3n5GHKsWwW2U+6u9J5RNKIvRzik=","X-Gm-Gg":"AeBDievvfGALZbIhOpBZue7sRPo85NcFb2N98Cno0yTgjEmrGmgSl2yCNMcuq0ya1y9\n XC6xGTyytFEUj/1uTP2fbWk3AfqI5+yVxpU/GvRuB7K19V3rqUPMY4G1mvmK22EqRB6PRjxZdPg\n oAu8YPF1yJi1ZAPt9WKbkIgnFkCkLPFHjVb2wSBMGPW4K5HFzsJBO3O1k62PkTnuM/9zxxLVQSw\n MfMKsGA0qWo/Q/lUCL9MxAO1PRRhS233F66VL9gxDCMc0mdVONDkFwsYF8HTa/aCIeXACujMtmr\n 3gQXyEiqpqd8heLTMIk7VGY0XPz/JiZwi7748pTWAKUlMC1oqCTUuUtqauspuGsOYUp7","X-Received":"by 2002:a05:6102:1483:b0:605:558d:c7c2 with SMTP id\n ada2fe7eead31-609ff0c1b4emr11105567137.12.1776284475113; Wed, 15 Apr 2026\n 13:21:15 -0700 (PDT)","MIME-Version":"1.0","References":"<53f26493-09fc-4f8b-9751-24d2c2e80697@linux.ibm.com>\n \n \n ","In-Reply-To":"\n ","Date":"Wed, 15 Apr 2026 13:21:02 -0700","X-Gm-Features":"AQROBzA8r9HH-Nf9i8y70cOjchP4rEIK2wmze41ac88q_PE9gJcAOnWgjlxHtvw","Message-ID":"\n ","To":"Jan Polensky ","X-Spam-Status":"No, score=-14.9 required=7.0 tests=DKIM_SIGNED,DKIM_VALID,\n DKIM_VALID_AU,DKIM_VALID_EF,ENV_AND_HDR_SPF_MATCH,SPF_HELO_NONE,\n SPF_PASS,USER_IN_DEF_DKIM_WL,USER_IN_DEF_SPF_WL shortcircuit=no\n autolearn=disabled version=4.0.1","X-Spam-Checker-Version":"SpamAssassin 4.0.1 (2024-03-25) on in-3.smtp.seeweb.it","X-Virus-Scanned":"clamav-milter 1.0.9 at in-3.smtp.seeweb.it","X-Virus-Status":"Clean","Subject":"Re: [LTP] [PATCH] sched_football: fix false failures on many-CPU\n systems","X-BeenThere":"ltp@lists.linux.it","X-Mailman-Version":"2.1.29","Precedence":"list","List-Id":"Linux Test Project ","List-Unsubscribe":",\n ","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n ","From":"John Stultz via ltp ","Reply-To":"John Stultz ","Cc":"Soma Das , ltp@lists.linux.it","Content-Type":"text/plain; charset=\"utf-8\"","Content-Transfer-Encoding":"base64","Errors-To":"ltp-bounces+incoming=patchwork.ozlabs.org@lists.linux.it","Sender":"\"ltp\" "}},{"id":3677911,"web_url":"http://patchwork.ozlabs.org/comment/3677911/","msgid":"","list_archive_url":null,"date":"2026-04-16T03:23:35","subject":"Re: [LTP] [PATCH] sched_football: fix false failures on many-CPU\n systems","submitter":{"id":74427,"url":"http://patchwork.ozlabs.org/api/people/74427/","name":"Li Wang","email":"wangli.ahau@gmail.com"},"content":"Hi John,\n\nJohn Stultz wrote:\n\n> > > > > 1. RT throttling freezes all SCHED_FIFO threads simultaneously. On\n> > > > > release, the kernel does not always reschedule the highest-priority\n> > > > > thread first on every CPU, so offense briefly runs and increments\n> > > > > the_ball before defense is rescheduled. Fix by saving and disabling\n> > > > > sched_rt_runtime_us in setup and restoring it in a new cleanup\n> > > > > callback.\n> > >\n> > > Make sense, and like the AI-reviewer points out LTP provides an option\n> > > to save_restore it automatically.\n>\n> Throttling shouldn't break the test. The fact that SCHED_NORMAL tasks\n> ran shouldn't change the ordering when we go back to running RT tasks.\n> This is likely a kernel bug.\n\nTheoretically speaking, your point is correct. While instant global\npriority ordering upon unthrottling is ideal, it ignores the physical realities\nof SMP architecture.\n\nIf we look at do_sched_rt_period_timer(), CPUs are unthrottled sequentially\nvia a for_each_cpu loop. When an early CPU in the loop is unlocked, it\nimmediately schedules its local RT task 'offense'.\nSee:\n https://elixir.bootlin.com/linux/v7.0/source/kernel/sched/rt.c#L797\n\nMeanwhile, subsequent CPUs in the loop (which may hold the higher-priority\n'defense' task) are literally still throttled.\n\nExpecting atomic, zero-latency global unthrottling is physically unrealistic for\nmulti-core systems.\n\nThat's why I tend to believe disabling throttling for this specific test is the\nwise and practical approach.\n\n\n> > > > > 2. Offense and defense threads were unpinned, allowing the scheduler\n> > > > > to migrate them freely. An offense thread could land on a CPU with\n> > > > > no defense thread present and run unchecked. Fix by passing a CPU\n> > > > > index as the thread arg and calling sched_setaffinity() at thread\n> > > > > start. Pairs are distributed round-robin (i % ncpus) so each\n> > > > > offense thread shares its CPU with a defense thread.\n> > >\n> > > This is a good thought, as for SCHED_FIFO it manages the corresponding\n> > > runqueue for each CPU and simply picks the higher priority task to run.\n> > > So pinning the threads to each CPU makes sense, but maybe we could\n> > > only pin the defense because:\n> > >\n> > > With N defense threads pinned one per CPU, every CPU has a defense\n> > > thread at priority 30 permanently runnable. The offense threads at priority\n> > > 15, regardless of which CPU the scheduler places them on, will always find\n> > > a higher-priority defense thread on the same CPU's runqueue. Since\n> > > SCHED_FIFO strictly favors the higher-priority runnable task, offense can\n> > > never be picked.\n> > >\n> > > Pinning offense as well would be redundant, it doesn't matter where offense\n> > > lands, because defense already covers every CPU. This also has the advantage\n> > > of letting the scheduler freely migrate offense threads without\n> > > affecting the test\n> > > outcome, which avoids interfering with the kernel's load balancing logic during\n> > > the test.\n> > >\n> > > And, I'd suggest using tst_ncpus_available() instead of get_numcpus()\n> > > when distributing defense threads across CPUs, in case some CPUs are\n> > > offline. Pinning a defense thread to an offline CPU would leave that\n> > > CPU uncovered and allow offense to run unchecked. See:\n>\n> I didn't see the orignal patch here, but the whole point of\n> sched_football is to ensure the top (unaffined) priority\n> tasks are always run and no lower priority rt tasks are run instead.\n>\n> So none of the tasks should be pinned to any cpus. The scheduler is\n> supposed to ensure the RT invariant holds.\n> There are some known bugs at the moment that will cause sched_football\n> to fail (the RT_PUSH_IPI feature, for instance). That's a problem with\n> the kernel, not the test.\n\nApart from the known bug of RT_PUSH_IPI feature, it still does not\nguarantee 100% success in real scenarios.\n\nAfter a deep look into the rt scheduler principals, I found that, because\nthe RT_PUSH_IPI mechanism is designed as a \"best-effort\"\noptimization rather than a guaranteed operation. As the kernel's\nscheduling state is highly dynamic and asynchronous, a push attempt\nwill deliberately abort if the environment changes between the time the\nIPI is sent and when it is actually processed.\n\nIt fails by design to prevent instability, primarily due to state expiration,\nCPU affinity restrictions, sudden priority inversions, or the lack of an\neligible target CPU.\n\nSee push_rt_task() in kernel/sched/rt.c:\n https://elixir.bootlin.com/linux/v7.0/source/kernel/sched/rt.c#L1939\n\nHence, if we explicitly pin the defense thread to each CPU, it will join in\nthe corresponding runqueues, which completely match the reasonable\nsituation: the kernel's RT scheduler guarantees per-CPU priority ordering,\nnot global placement. The RT load balancer is asynchronous and doesn't\nguarantee that all high-priority threads are placed before any low-priority\nthread runs.\n\nOn the other side, if the test expects a global guarantee, it's testing\nsomething the kernel doesn't claim to provide.\n\nTo the rest changes, the current test has several non-kernel issues\n(RT throttling interference, uninitialized game_over on reruns, silent\nsched_setscheduler failures) that produce false failures. These mask\nthe real kernel bugs you want to detect.\n\n\n--\nRegards,\nLi Wang","headers":{"Return-Path":"","X-Original-To":["incoming@patchwork.ozlabs.org","ltp@lists.linux.it"],"Delivered-To":["patchwork-incoming@legolas.ozlabs.org","ltp@picard.linux.it"],"Authentication-Results":["legolas.ozlabs.org;\n\tdkim=fail reason=\"signature verification failed\" (2048-bit key;\n unprotected) header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256\n header.s=20251104 header.b=UI1u4xv1;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=lists.linux.it\n (client-ip=2001:1418:10:5::2; helo=picard.linux.it;\n envelope-from=ltp-bounces+incoming=patchwork.ozlabs.org@lists.linux.it;\n receiver=patchwork.ozlabs.org)"],"Received":["from picard.linux.it (picard.linux.it [IPv6:2001:1418:10:5::2])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange x25519 server-signature ECDSA (secp384r1) server-digest SHA384)\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4fx3JV0zCBz1yDF\n\tfor ; Thu, 16 Apr 2026 13:23:53 +1000 (AEST)","from picard.linux.it (localhost [IPv6:::1])\n\tby picard.linux.it (Postfix) with ESMTP id 6CDF93E4EF4\n\tfor ; Thu, 16 Apr 2026 05:23:51 +0200 (CEST)","from in-5.smtp.seeweb.it (in-5.smtp.seeweb.it\n [IPv6:2001:4b78:1:20::5])\n (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n key-exchange X25519 server-signature ECDSA (secp384r1))\n (No client certificate requested)\n by picard.linux.it (Postfix) with ESMTPS id 3B0343C9917\n for ; Thu, 16 Apr 2026 05:23:47 +0200 (CEST)","from mail-qv1-xf2f.google.com (mail-qv1-xf2f.google.com\n [IPv6:2607:f8b0:4864:20::f2f])\n (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)\n key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest\n SHA256)\n (No client certificate requested)\n by in-5.smtp.seeweb.it (Postfix) with ESMTPS id 69BB3600856\n for ; Thu, 16 Apr 2026 05:23:47 +0200 (CEST)","by mail-qv1-xf2f.google.com with SMTP id\n 6a1803df08f44-8acae26e564so48899306d6.2\n for ; Wed, 15 Apr 2026 20:23:47 -0700 (PDT)"],"ARC-Seal":"i=1; a=rsa-sha256; t=1776309826; cv=none;\n d=google.com; s=arc-20240605;\n b=BnkgLjYdeWfInRw2jj4jrp2RgNrFfnJDoGNGOjo4GMeDRrSgf5QcgdfHzJATlGSvK5\n JMuAVPJazgngSwKJbzGqZ0neyvwxMxpHuURUJFg4wtxwBwy73e2cXGxWdXyPcqclaYuW\n BE7CCAC2dR2Wxo2lyKcph8II2/OEcqIed37rIEOma5LVPiuT2Fl40rGmXVbm/fM9iDvR\n s+DXEVUY5/iwD0/d63ecN6EPHJ3SqMcROeROYQvtezFchU9Ri6X/u2mJVZx+0lVykx+j\n nbPASuBYr4C2PbK48gkxrJztXYPK1NMShIZbBkx1wwFQ5CCiFvMeQFfIFSZKe/OyjQNp\n vcSA==","ARC-Message-Signature":"i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com;\n s=arc-20240605;\n h=cc:to:subject:message-id:date:from:in-reply-to:references\n :mime-version:dkim-signature;\n bh=A4rthckyVd/14S41RuSoOr2gtvTbB1cvvhKPzRFidPo=;\n fh=D6MNrfoLb+fmFM8qJq1MC0gBbNmJfgEDhu6yddyYbAY=;\n b=T5stwM4EAOssbuMuZLkDqXJpt71YGPteT7obWg0LTl/LFeZcteUkGy9uwqgxyFVvac\n 1FFfPkWTbaoLnRzxHBWbjlRfxU73dK9Aq0bXe+n4FbzAwEQBEE4RkjeKT4ahzP6tyI1/\n 2HCSpmOF4SDPXttYbTBzloW0CMVEvJZbiVYk8nvTvj+74+MFX5W8JRvq6nX2CYXRST1i\n UPPQPqlZw5O/F0WUgnTajF4EXmwDw0dWzJTQdfrw0aXQniTnazaB09d04u41aTcz31uP\n sCZlqfoFZ6h4MWrKt7pinjPhUBFLH8gduoTucxVwA/cVUic4wqB1mzFeuPKWbTKfAAV5\n 5jVA==; darn=lists.linux.it","ARC-Authentication-Results":"i=1; mx.google.com; arc=none","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n d=gmail.com; s=20251104; t=1776309826; x=1776914626; darn=lists.linux.it;\n h=cc:to:subject:message-id:date:from:in-reply-to:references\n :mime-version:from:to:cc:subject:date:message-id:reply-to;\n bh=A4rthckyVd/14S41RuSoOr2gtvTbB1cvvhKPzRFidPo=;\n b=UI1u4xv1b+Mgkl7nxujcSWNGZz9oKOKujwWZ8l68Id2YhY3GJAS5LTL1/iee79gX84\n g4GnbcV7Udz940o6ZU1QQivf1ekyGiVYQXaSsK8tptb+DgAEkXuvZb/ryEUk22Jq+t07\n FfFDUYOXkwb+y3MFyjTzNaNJXFM9xyLTCMWMa8LZ4TJh0PDS2sPyAgRjQ6v0P3W2hWry\n WCfEBYtsEBYP3KMefBKCkG2+qrUSEDahk+5cQQ35vLcVdJ8OqVipu1F4XvWurfsOexS0\n q3a9EI13v0STvQ1p8NvYCgEpuw+WqkLw/bTqhn8XQvOEopBWxBlOEol2hyaG+ZuNjPxt\n hfMw==","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n d=1e100.net; s=20251104; t=1776309826; x=1776914626;\n h=cc:to:subject:message-id:date:from:in-reply-to:references\n :mime-version:x-gm-gg:x-gm-message-state:from:to:cc:subject:date\n :message-id:reply-to;\n bh=A4rthckyVd/14S41RuSoOr2gtvTbB1cvvhKPzRFidPo=;\n b=o5YjaT3Q08k1bOwCNRiWTvGmuZl47nYDLh/fjum7rW3sMW9oA5df8jgIyZQi4uMqxE\n b40whZXY2nPYqB5iM/SdV0ERT6q9vXmP3hJ/8molMg35f0VIOyIIzZmqgiTO/GE8Ch/Z\n IXpbG0Vdz4a5I/v3FIfGPddQ0YAs7C60rV0jqgZDJedtgqgG/VILSvaPxhSOFu61MoMR\n o50E0tvCVCuyD/43KbAJdAyZqgeBB7O5+zkrPb0G9w2zrzIVLIQPrQxdDLxoZteK6fCg\n zN/M27j0bVCd4da7tiDG7VpKzMGH5DLVtanFTq7AuhNdGAGMuJEHSjPkkUlYT+jh3oXk\n Yucg==","X-Forwarded-Encrypted":"i=1;\n AFNElJ/DZjb9uM1ZMKW6wF5ayQYlc5MoCaWLky4ZzNzfdbfoEybC4YX301+aN9YEj/neN8sp/cY=@lists.linux.it","X-Gm-Message-State":"AOJu0YxL+wkYhAtTr62IhKeijUwV0xQbddVtSREk0mRjJKD8AeYm6D5X\n O8f9WKBwRlNfhUX/tH/Vrh1dCliwR1W1N1oUc84e6Gfy+w86AZesrmTE7botOA6/4YZFvUDUcrp\n cL4t2TC0NDmtZX5Sliv4SjPxxMFtuig==","X-Gm-Gg":"AeBDievHh1Ar5AC06j3fB0bNXoJT7f2ALPbg48pDu4K/V/2RslmeJ6iqobGM782zp1l\n /9zZvKjpUq8NoB5cu7OxZLq8zdavV3AHCyBYQFn2UFV5O1cGZvys7/h98eXg0bMscKqKaG7E9cs\n v5dae+sflDkEwgNBPjSUldamSFUbcChZRKtXBIz2FOzIyGGd3kjf3Karc77TRGB0ZhmXorHpDWf\n 84leLsZpKROj9bvO++PmqqzvI+Eke+78V1rAsGpg1XKw/q+Xgp/YLEf+uqDf0ACn85wR6t0nbHt\n MdBdOX+RvR9x/ZU3hI6qrYbV/Sw=","X-Received":"by 2002:a0c:e016:0:b0:89e:e841:1f25 with SMTP id\n 6a1803df08f44-8ac860ba93fmr364391416d6.11.1776309826147; Wed, 15 Apr 2026\n 20:23:46 -0700 (PDT)","MIME-Version":"1.0","References":"<53f26493-09fc-4f8b-9751-24d2c2e80697@linux.ibm.com>\n \n \n \n ","In-Reply-To":"\n ","From":"Li Wang ","Date":"Thu, 16 Apr 2026 11:23:35 +0800","X-Gm-Features":"AQROBzBE4YR9Jl_uz2eeZfsK2vgKERZevAyQCzXHh7V4PvrdYtRbKD6Pr6hid0s","Message-ID":"\n ","To":"John Stultz ","X-Spam-Status":"No, score=1.1 required=7.0 tests=DKIM_SIGNED,DKIM_VALID,\n DKIM_VALID_AU,DKIM_VALID_EF,FORGED_GMAIL_RCVD,FREEMAIL_FROM,\n SPF_HELO_NONE,SPF_PASS shortcircuit=no autolearn=disabled version=4.0.1","X-Spam-Level":"*","X-Spam-Checker-Version":"SpamAssassin 4.0.1 (2024-03-25) on in-5.smtp.seeweb.it","X-Virus-Scanned":"clamav-milter 1.0.9 at in-5.smtp.seeweb.it","X-Virus-Status":"Clean","Subject":"Re: [LTP] [PATCH] sched_football: fix false failures on many-CPU\n systems","X-BeenThere":"ltp@lists.linux.it","X-Mailman-Version":"2.1.29","Precedence":"list","List-Id":"Linux Test Project ","List-Unsubscribe":",\n ","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n ","Cc":"Soma Das , ltp@lists.linux.it","Content-Type":"text/plain; charset=\"us-ascii\"","Content-Transfer-Encoding":"7bit","Errors-To":"ltp-bounces+incoming=patchwork.ozlabs.org@lists.linux.it","Sender":"\"ltp\" "}},{"id":3677945,"web_url":"http://patchwork.ozlabs.org/comment/3677945/","msgid":"","list_archive_url":null,"date":"2026-04-16T05:53:56","subject":"Re: [LTP] [PATCH] sched_football: fix false failures on many-CPU\n systems","submitter":{"id":74427,"url":"http://patchwork.ozlabs.org/api/people/74427/","name":"Li Wang","email":"wangli.ahau@gmail.com"},"content":"> That's why I tend to believe disabling throttling for this specific test is the\n> wise and practical approach.\n\nHowever, back to the original patch, disabling throttling was\nindeed a bit of an overprotection based on the pined method\n(I didn't realize that before).\n\nOnce we go with pin 'defense' threads to every CPU, while leaving\nthe offense thread unpinned, this throttling can be kept enabled.\n\nWhichever CPU gets unthrottled first will instantly execute its local\ndefensetask, completely starving the lower-priority offense task.\n\nIt relies on strict local preemption to perfectly mask the SMP sequential\nunthrottling latency, fixing the test without needing to disable\nsched_rt_runtime_us in the kernel.","headers":{"Return-Path":"","X-Original-To":["incoming@patchwork.ozlabs.org","ltp@lists.linux.it"],"Delivered-To":["patchwork-incoming@legolas.ozlabs.org","ltp@picard.linux.it"],"Authentication-Results":["legolas.ozlabs.org;\n\tdkim=fail reason=\"signature verification failed\" (2048-bit key;\n unprotected) header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256\n header.s=20251104 header.b=nsmgjyTm;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=lists.linux.it\n (client-ip=2001:1418:10:5::2; helo=picard.linux.it;\n envelope-from=ltp-bounces+incoming=patchwork.ozlabs.org@lists.linux.it;\n receiver=patchwork.ozlabs.org)"],"Received":["from picard.linux.it (picard.linux.it [IPv6:2001:1418:10:5::2])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange x25519 server-signature ECDSA (secp384r1) server-digest SHA384)\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4fx6f11drMz1yDF\n\tfor ; Thu, 16 Apr 2026 15:54:17 +1000 (AEST)","from picard.linux.it (localhost [IPv6:::1])\n\tby picard.linux.it (Postfix) with ESMTP id D66C73E128E\n\tfor ; Thu, 16 Apr 2026 07:54:14 +0200 (CEST)","from in-4.smtp.seeweb.it (in-4.smtp.seeweb.it\n [IPv6:2001:4b78:1:20::4])\n (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n key-exchange X25519 server-signature ECDSA (secp384r1))\n (No client certificate requested)\n by picard.linux.it (Postfix) with ESMTPS id 4A4D33CC8C5\n for ; Thu, 16 Apr 2026 07:54:09 +0200 (CEST)","from mail-qv1-xf31.google.com (mail-qv1-xf31.google.com\n [IPv6:2607:f8b0:4864:20::f31])\n (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)\n key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest\n SHA256)\n (No client certificate requested)\n by in-4.smtp.seeweb.it (Postfix) with ESMTPS id 21930100036A\n for ; Thu, 16 Apr 2026 07:54:09 +0200 (CEST)","by mail-qv1-xf31.google.com with SMTP id\n 6a1803df08f44-8a48deebe95so61538076d6.0\n for ; Wed, 15 Apr 2026 22:54:09 -0700 (PDT)"],"ARC-Seal":"i=1; a=rsa-sha256; t=1776318848; cv=none;\n d=google.com; s=arc-20240605;\n b=GEKoO5cAR/PHl1ObLsyge6UOHAWNqL08C5nLTMjbgQHgNcg4S8KTh83mOphF6a5wU/\n giGUZjZ5VhSC4EI8wzkKrzehEBK4S5Rk1oOPCwfeUYB1Kix2ddSQkJkDUNWBKbaQ15eG\n 3GCdIYQdZlfVFsE+/hKUuALNCst3PxFXspDInFjbg1AlZnA7GofJCKOdV1gJ8U21G4jP\n UDVafr8HquZaG+e6zuVPH0pbQvBMnIK/HYWf3OAqoKHJhz1fk/15GqIgy5RWIG5iSYFn\n Ru+yGRI85EdkSt+Z6LUdBoQtKhHJYzEiA5OSyJpSd+PUewnQUaoEf3q1RR3ytZR2icKT\n XBWg==","ARC-Message-Signature":"i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com;\n s=arc-20240605;\n h=cc:to:subject:message-id:date:from:in-reply-to:references\n :mime-version:dkim-signature;\n bh=UEnf5nuuvMIrDPrcqmo6YPelq4gS5QlbqZxeb3GFQaE=;\n fh=Zfzk/SUJ4TmbaA4JA+azdFJ3XHdG+bxusN5ghhPguT4=;\n b=TFzcl4uHd8HiOmZ9F6+1ioV0EbR/V8L6KRMbnm7nvfPhdaVIN8F/JuejcetKvMuDMO\n 4CB5vU4R/yA0FsahO2ugcLrzfZABkRb/OLGafsZKStCYdzoEtp9CD8JjKoWFFKhtTke6\n 5Q5vJUhulJQ0eHNqYcHRsxIiWZjIDcR1S+SQGRjIBw9wsiSWpoXb5/aD+C/i2hJIltb0\n /WcEukvvwXlcMxedxs6EALepx5zEHCN9XWL2Ni3/EjDd/mNrj1txarJO9Z/Tgsr8sZPS\n 8xDT9J99veILTTxe/pbpdiLo1HIV+8wbuMC3vggLFgmzdojnm3At/Fww32BMcatlEnTt\n M4mQ==; darn=lists.linux.it","ARC-Authentication-Results":"i=1; mx.google.com; arc=none","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n d=gmail.com; s=20251104; t=1776318848; x=1776923648; darn=lists.linux.it;\n h=cc:to:subject:message-id:date:from:in-reply-to:references\n :mime-version:from:to:cc:subject:date:message-id:reply-to;\n bh=UEnf5nuuvMIrDPrcqmo6YPelq4gS5QlbqZxeb3GFQaE=;\n b=nsmgjyTmNT+SlgQ3D06Zp8594Gu4kChnyNqelJF/PvtDu3HVdwk4zv1eAfCJWY/Av7\n rpqi9pV/O3frpXlEEOR06dyX0u59omROVVYkiEiMfp7zD+RZ0jdV7YHe0WFihGcoKcIN\n dHTvyMfjIso8eeH31VRGY5p3MQIyvygzuaxXlkt8AgrYwm6NYfK//oYOcs9BLw4d1RE5\n F9LHgUaSLKHThMsnJsfyyZdP/GW7C+XExPWeOAJpawTWZLbUyZwkHhaOFMjGd7tj1Uh9\n sNwCgm5Zpv9TYLjFKo9EN78BEsmhH+SPgsIhEjT+SlUN6R9jh0OrD9gI5z03jsYQbcE4\n dAYA==","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n d=1e100.net; s=20251104; t=1776318848; x=1776923648;\n h=cc:to:subject:message-id:date:from:in-reply-to:references\n :mime-version:x-gm-gg:x-gm-message-state:from:to:cc:subject:date\n :message-id:reply-to;\n bh=UEnf5nuuvMIrDPrcqmo6YPelq4gS5QlbqZxeb3GFQaE=;\n b=h1MKTumd46xqDsO0WR9jNGJfq6Bs9AH9RlvobcFN1UuvNKGCdHqMQ/2/M7r1u5kHI4\n z7SzO5DVJYmCXTpBuFaBBY4gdmQY+//b+Ok4jRoMbyk2HxwTJFztltRxRpE70iDgj6V9\n ILJQJCsiWkEW22dtir4rYgxLtE75akqaZ1qZJJwo8ZdzzjPHXTIAPDNSyiwg+CHgL/UL\n A0F9m97SJTiGLvqjlm4SK7QCCcbj4SkI45rOqT6iyLq+Zbzmaz/hAx1cmGbCV2eytYps\n dR8G86FPEoinC4GkK6BZ6Ndcz1w4b5+sgCjHkxwH+QH4wNTZiZ0nCBAhEYxJkyGNre+V\n RXTA==","X-Forwarded-Encrypted":"i=1;\n AFNElJ+l9T9l6lmS2EK8VTdLZ5qCdWQkSyotZtpsQtBfMqSHdi2t6L3FckPb//EkOoIHrmZAWZo=@lists.linux.it","X-Gm-Message-State":"AOJu0Yx7B2wyyyb9fTChyHLqiorpAeEajujk5v0MwgRNmzcFNTYm+/QQ\n 2KLtG+VSvKzDwYPvibAsJKWUygSgntRTkwAxUU7mOBvBoHljhVq0SWJW/y6v6X3JDJt+U62AW9s\n TUuel791rTA0lZtQ9CkGmp7BBmIzmuw==","X-Gm-Gg":"AeBDietfih4dbVD3ndIknUFbiaVaWEvCDE6c/46dCdEkUSjOF7qqVtlnA7tuashYOQ4\n T/v3IcxwGgGQO1H7zdm2F7H/H9y1WDVfoLzMDxsF0eqgK8dxQK/jgR4XDo65mulhGU/yAkCYM6L\n 47isnwc2VdThIpJdJiBlpQN0Rfq/Yucu9ygQ5VzeoZEYfz3QCcXlpIrBNWrFlAbsUSOx/h2FkLm\n MWV8/opo4avKSOwLYogmeaN+KfYiM9RpT3t0XiFbWtsxDjaO2eedSQpf7mbiFZTABp1sItSt+vM\n A1t7KJ/Vq0/5kirv","X-Received":"by 2002:ad4:574d:0:b0:8a6:1216:fb6f with SMTP id\n 6a1803df08f44-8ac862e0dbcmr421107156d6.32.1776318847838; Wed, 15 Apr 2026\n 22:54:07 -0700 (PDT)","MIME-Version":"1.0","References":"<53f26493-09fc-4f8b-9751-24d2c2e80697@linux.ibm.com>\n \n \n \n \n ","In-Reply-To":"\n ","From":"Li Wang ","Date":"Thu, 16 Apr 2026 13:53:56 +0800","X-Gm-Features":"AQROBzB2J1QZbopKSEJlKnBNFO4hA87MrmAJ9ie2enoPgZHku68KaM6R-AxmGew","Message-ID":"\n ","To":"John Stultz ","X-Spam-Status":"No, score=1.1 required=7.0 tests=DKIM_SIGNED,DKIM_VALID,\n DKIM_VALID_AU,DKIM_VALID_EF,FORGED_GMAIL_RCVD,FREEMAIL_FROM,\n SPF_HELO_NONE,SPF_PASS shortcircuit=no autolearn=disabled version=4.0.1","X-Spam-Level":"*","X-Spam-Checker-Version":"SpamAssassin 4.0.1 (2024-03-25) on in-4.smtp.seeweb.it","X-Virus-Scanned":"clamav-milter 1.0.9 at in-4.smtp.seeweb.it","X-Virus-Status":"Clean","Subject":"Re: [LTP] [PATCH] sched_football: fix false failures on many-CPU\n systems","X-BeenThere":"ltp@lists.linux.it","X-Mailman-Version":"2.1.29","Precedence":"list","List-Id":"Linux Test Project ","List-Unsubscribe":",\n ","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n ","Cc":"Soma Das , ltp@lists.linux.it","Content-Type":"text/plain; charset=\"us-ascii\"","Content-Transfer-Encoding":"7bit","Errors-To":"ltp-bounces+incoming=patchwork.ozlabs.org@lists.linux.it","Sender":"\"ltp\" "}},{"id":3678000,"web_url":"http://patchwork.ozlabs.org/comment/3678000/","msgid":"<17da2ea7-b1f8-49ab-95ed-30083592e7fa@linux.ibm.com>","list_archive_url":null,"date":"2026-04-16T08:26:17","subject":"Re: [LTP] [PATCH] sched_football: fix false failures on many-CPU\n systems","submitter":{"id":93035,"url":"http://patchwork.ozlabs.org/api/people/93035/","name":"Soma Das","email":"somadas1@linux.ibm.com"},"content":"Hi Li, Jan, John,\n\nThank you all for the detailed review and discussion.\n\nBased on the feedback, here is what I plan to incorporate in v2:\n\n *\n\n Pin only defense threads (one per CPU), leave offense unpinned\n\n *\n\n Replace |get_numcpus()| with |tst_ncpus_available()| to handle\n offline CPUs\n\n *\n\n Drop the RT throttle disabling entirely - unnecessary once defense\n is pinned per CPU\n\n *\n\n Remove the |usleep()| / |tst_check_preempt_rt()| block after kickoff\n\n *\n\n Add |join_threads()| before |pthread_barrier_destroy()| for clean\n |-i N| reruns (thanks Jan for catching this)\n\n *\n\n Split into separate patches - at minimum fixes #3 and #4 will be\n separate\n\n *\n\n Update commit message to clarify the test now verifies per-CPU\n SCHED_FIFO priority ordering\n\nWill send v2 soon.\n\nThanks,\nSoma\n\n\nOn 16/04/26 11:23 AM, Li Wang wrote:\n>> That's why I tend to believe disabling throttling for this specific test is the\n>> wise and practical approach.\n> However, back to the original patch, disabling throttling was\n> indeed a bit of an overprotection based on the pined method\n> (I didn't realize that before).\n>\n> Once we go with pin 'defense' threads to every CPU, while leaving\n> the offense thread unpinned, this throttling can be kept enabled.\n>\n> Whichever CPU gets unthrottled first will instantly execute its local\n> defensetask, completely starving the lower-priority offense task.\n>\n> It relies on strict local preemption to perfectly mask the SMP sequential\n> unthrottling latency, fixing the test without needing to disable\n> sched_rt_runtime_us in the kernel.\n>","headers":{"Return-Path":"","X-Original-To":["incoming@patchwork.ozlabs.org","ltp@lists.linux.it"],"Delivered-To":["patchwork-incoming@legolas.ozlabs.org","ltp@picard.linux.it"],"Authentication-Results":["legolas.ozlabs.org;\n\tdkim=fail reason=\"signature verification failed\" (2048-bit key;\n unprotected) header.d=ibm.com header.i=@ibm.com header.a=rsa-sha256\n header.s=pp1 header.b=YZ+nOG/O;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=lists.linux.it\n (client-ip=2001:1418:10:5::2; helo=picard.linux.it;\n envelope-from=ltp-bounces+incoming=patchwork.ozlabs.org@lists.linux.it;\n receiver=patchwork.ozlabs.org)"],"Received":["from picard.linux.it (picard.linux.it [IPv6:2001:1418:10:5::2])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange x25519 server-signature ECDSA (secp384r1) server-digest SHA384)\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4fxB1l01wHz1yCv\n\tfor ; Thu, 16 Apr 2026 18:26:34 +1000 (AEST)","from picard.linux.it (localhost [IPv6:::1])\n\tby picard.linux.it (Postfix) with ESMTP id 1B1583E2633\n\tfor ; Thu, 16 Apr 2026 10:26:32 +0200 (CEST)","from in-3.smtp.seeweb.it (in-3.smtp.seeweb.it [217.194.8.3])\n (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n key-exchange X25519 server-signature ECDSA (secp384r1))\n (No client certificate requested)\n by picard.linux.it (Postfix) with ESMTPS id 8E7963D87C1\n for ; Thu, 16 Apr 2026 10:26:28 +0200 (CEST)","from mx0b-001b2d01.pphosted.com (mx0b-001b2d01.pphosted.com\n [148.163.158.5])\n (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest\n SHA256)\n (No client certificate requested)\n by in-3.smtp.seeweb.it (Postfix) with ESMTPS id 3CE541A00706\n for ; Thu, 16 Apr 2026 10:26:26 +0200 (CEST)","from pps.filterd (m0356516.ppops.net [127.0.0.1])\n by mx0a-001b2d01.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id\n 63FNtrod127659; Thu, 16 Apr 2026 08:26:25 GMT","from ppma12.dal12v.mail.ibm.com\n (dc.9e.1632.ip4.static.sl-reverse.com [50.22.158.220])\n by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 4dh89pkmb6-1\n (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT);\n Thu, 16 Apr 2026 08:26:24 +0000 (GMT)","from pps.filterd (ppma12.dal12v.mail.ibm.com [127.0.0.1])\n by ppma12.dal12v.mail.ibm.com (8.18.1.2/8.18.1.2) with ESMTP id\n 63G6FXeI015164;\n Thu, 16 Apr 2026 08:26:23 GMT","from smtprelay03.dal12v.mail.ibm.com ([172.16.1.5])\n by ppma12.dal12v.mail.ibm.com (PPS) with ESMTPS id 4dg0mst840-1\n (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT);\n Thu, 16 Apr 2026 08:26:23 +0000","from smtpav01.wdc07v.mail.ibm.com (smtpav01.wdc07v.mail.ibm.com\n [10.39.53.228])\n by smtprelay03.dal12v.mail.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id\n 63G8QNOd21824240\n (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);\n Thu, 16 Apr 2026 08:26:23 GMT","from smtpav01.wdc07v.mail.ibm.com (unknown [127.0.0.1])\n by IMSVA (Postfix) with ESMTP id E60C658055;\n Thu, 16 Apr 2026 08:26:22 +0000 (GMT)","from smtpav01.wdc07v.mail.ibm.com (unknown [127.0.0.1])\n by IMSVA (Postfix) with ESMTP id 6621F5804B;\n Thu, 16 Apr 2026 08:26:20 +0000 (GMT)","from [9.123.5.88] (unknown [9.123.5.88])\n by smtpav01.wdc07v.mail.ibm.com (Postfix) with ESMTPS;\n Thu, 16 Apr 2026 08:26:20 +0000 (GMT)"],"DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed; d=ibm.com; h=cc\n :content-transfer-encoding:content-type:date:from:in-reply-to\n :message-id:mime-version:references:subject:to; s=pp1; bh=escKvo\n yUcuJkQSKnvstUwO6v4ZAKcqHu/LaHpIGl9NY=; b=YZ+nOG/O/q4ZDMAgHxHvra\n sVjSmDJcLbZ4hqwxdVOi5emSmLku78S5Es+X8LyVFfdlExUlE8KnATFBDUklFbw5\n IhpGlKMMasqJolvysD5Exmt0ArF0nc7BpSXE4ByWmRiPfvgYDEnPcN44QG22tPwb\n CmLYmtSzeoZcZobFbi7JgdExmGJ7P+qfbvsHYj1dy9UzX3LP8hx1O6nAvYDnmDx1\n WSc4XugtbqdSSNR2xlFoFJ97GekJe+8o0fk/s3P8KDhHBCS8Plvb9RdbjZYxlJ1d\n +CYLlPIMfwZNPrA1d/PBmAbvh8Kf2vpqVwJ0SV7QWSorqb53stIsslZipjVZZNuQ\n ==","Message-ID":"<17da2ea7-b1f8-49ab-95ed-30083592e7fa@linux.ibm.com>","Date":"Thu, 16 Apr 2026 13:56:17 +0530","MIME-Version":"1.0","User-Agent":"Mozilla Thunderbird","To":"Li Wang , John Stultz ","References":"<53f26493-09fc-4f8b-9751-24d2c2e80697@linux.ibm.com>\n \n \n \n \n \n ","Content-Language":"en-US","From":"Soma Das ","In-Reply-To":"\n ","X-TM-AS-GCONF":"00","X-Proofpoint-Reinject":"loops=2 maxloops=12","X-Proofpoint-GUID":"Xw79PeZSH08ZvO9XTzi8mQcnVFfe_6sf","X-Proofpoint-ORIG-GUID":"OMrDFgDoHn6SIW407WEhkZEh1Pqe6gnm","X-Authority-Analysis":"v=2.4 cv=WbE8rUhX c=1 sm=1 tr=0 ts=69e09d30 cx=c_pps\n a=bLidbwmWQ0KltjZqbj+ezA==:117 a=bLidbwmWQ0KltjZqbj+ezA==:17\n a=IkcTkHD0fZMA:10 a=A5OVakUREuEA:10 a=VkNPw1HP01LnGYTKEx00:22\n a=RnoormkPH1_aCDwRdu11:22 a=Y2IxJ9c9Rs8Kov3niI8_:22 a=T3dXcuBNJUA-V_xk3z0A:9\n a=QEXdDO2ut3YA:10","X-Proofpoint-Spam-Details-Enc":"AW1haW4tMjYwNDE2MDA3NyBTYWx0ZWRfX0uDAvJCwYQbQ\n BvwCTOPtOskQZ8JLp86iAAvu8Qvya1QZJ3HCkjEHBr8FSuB3mQA3HB3IKKLCLwYMSDd30W+wTJ4\n S/43pyNRHhpx/CcN0vVgdkEtPoLegrzKGubB7i1bkYf8oR3IG+rVzHfepo/tzMdIO98YQMESIMq\n FTDO9AEob1Mn3DmUxSjBMPxqwB3z9CtYkg8FDwNefPIv/x234yRnPeSiFEt0Ga02BX2s1GOstQ1\n GBbRiusJljycnD3ZhG/SxOTVaYLTRsqzwnhEfWwsQaJwn21rYQrVvxaXugQ+CgUH2jUTxYwDCZU\n eIZZ3sw/oLSsWSI1ESYRARtbQqjFXtSSB8r5ZbX2ynFHOCtgEOsEj7j/gTE0KFjRmMw0p+1zl6x\n az/QqiHQNt9a8PWqnfCw/BaNT7yQL0m2ppr+8yDZzvUkhc7LPhYF+cRmgcgkkMN6jJ0C0LtAi52\n ySpdNOtYEJJpu74TRfg==","X-Proofpoint-Virus-Version":"vendor=baseguard\n engine=ICAP:2.0.293,Aquarius:18.0.1143,Hydra:6.1.51,FMLib:17.12.100.49\n definitions=2026-04-16_02,2026-04-13_04,2025-10-01_01","X-Proofpoint-Spam-Details":"rule=outbound_notspam policy=outbound score=0\n suspectscore=0 bulkscore=0 priorityscore=1501 spamscore=0 clxscore=1011\n phishscore=0 impostorscore=0 adultscore=0 malwarescore=0 lowpriorityscore=0\n classifier=typeunknown authscore=0 authtc= authcc= route=outbound adjust=0\n reason=mlx scancount=1 engine=8.22.0-2604070000 definitions=main-2604160077","X-Spam-Status":"No, score=0.1 required=7.0 tests=DKIM_SIGNED,DKIM_VALID,\n SPF_HELO_NONE,SPF_PASS shortcircuit=no autolearn=disabled version=4.0.1","X-Spam-Checker-Version":"SpamAssassin 4.0.1 (2024-03-25) on in-3.smtp.seeweb.it","X-Virus-Scanned":"clamav-milter 1.0.9 at in-3.smtp.seeweb.it","X-Virus-Status":"Clean","Subject":"Re: [LTP] [PATCH] sched_football: fix false failures on many-CPU\n systems","X-BeenThere":"ltp@lists.linux.it","X-Mailman-Version":"2.1.29","Precedence":"list","List-Id":"Linux Test Project ","List-Unsubscribe":",\n ","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n ","Cc":"ltp@lists.linux.it","Content-Transfer-Encoding":"7bit","Content-Type":"text/plain; charset=\"us-ascii\"; Format=\"flowed\"","Errors-To":"ltp-bounces+incoming=patchwork.ozlabs.org@lists.linux.it","Sender":"\"ltp\" "}},{"id":3678011,"web_url":"http://patchwork.ozlabs.org/comment/3678011/","msgid":"","list_archive_url":null,"date":"2026-04-16T08:40:36","subject":"Re: [LTP] [PATCH] sched_football: fix false failures on many-CPU\n systems","submitter":{"id":74427,"url":"http://patchwork.ozlabs.org/api/people/74427/","name":"Li Wang","email":"wangli.ahau@gmail.com"},"content":"Soma Das wrote:\n\n> Based on the feedback, here is what I plan to incorporate in v2:\n>\n> * Pin only defense threads (one per CPU), leave offense unpinned\n>\n> * Replace |get_numcpus()| with |tst_ncpus_available()| to handle\n> offline CPUs\n>\n> * Drop the RT throttle disabling entirely - unnecessary once defense\n> is pinned per CPU\n>\n> * Remove the |usleep()| / |tst_check_preempt_rt()| block after kickoff\n>\n> * Add |join_threads()| before |pthread_barrier_destroy()| for clean\n> |-i N| reruns (thanks Jan for catching this)\n>\n> * Split into separate patches - at minimum fixes #3 and #4 will be\n> separate\n>\n> * Update commit message to clarify the test now verifies per-CPU\n> SCHED_FIFO priority ordering\n\nGenerally that's my expected revision, but I would suggest you wait for\nJohn's reply to see if he has other suggestions.\n(John is an expert in schedulers :)\n\nBut you can test the v2 on your side and feedback here firstly.","headers":{"Return-Path":"","X-Original-To":["incoming@patchwork.ozlabs.org","ltp@lists.linux.it"],"Delivered-To":["patchwork-incoming@legolas.ozlabs.org","ltp@picard.linux.it"],"Authentication-Results":["legolas.ozlabs.org;\n\tdkim=fail reason=\"signature verification failed\" (2048-bit key;\n unprotected) header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256\n header.s=20251104 header.b=WAYzjZNp;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=lists.linux.it\n (client-ip=2001:1418:10:5::2; helo=picard.linux.it;\n envelope-from=ltp-bounces+incoming=patchwork.ozlabs.org@lists.linux.it;\n receiver=patchwork.ozlabs.org)"],"Received":["from picard.linux.it (picard.linux.it [IPv6:2001:1418:10:5::2])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange x25519)\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4fxBLG1h8mz1yCv\n\tfor ; Thu, 16 Apr 2026 18:40:54 +1000 (AEST)","from picard.linux.it (localhost [IPv6:::1])\n\tby picard.linux.it (Postfix) with ESMTP id E28143E2924\n\tfor ; Thu, 16 Apr 2026 10:40:51 +0200 (CEST)","from in-7.smtp.seeweb.it (in-7.smtp.seeweb.it\n [IPv6:2001:4b78:1:20::7])\n (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n key-exchange X25519 server-signature ECDSA (secp384r1))\n (No client certificate requested)\n by picard.linux.it (Postfix) with ESMTPS id 597923D87C1\n for ; Thu, 16 Apr 2026 10:40:49 +0200 (CEST)","from mail-qt1-x835.google.com (mail-qt1-x835.google.com\n [IPv6:2607:f8b0:4864:20::835])\n (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)\n key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest\n SHA256)\n (No client certificate requested)\n by in-7.smtp.seeweb.it (Postfix) with ESMTPS id F3DF12002D2\n for ; Thu, 16 Apr 2026 10:40:48 +0200 (CEST)","by mail-qt1-x835.google.com with SMTP id\n d75a77b69052e-50b29c4e554so79227941cf.0\n for ; Thu, 16 Apr 2026 01:40:48 -0700 (PDT)"],"ARC-Seal":"i=1; a=rsa-sha256; t=1776328848; cv=none;\n d=google.com; s=arc-20240605;\n b=U0lVB4hm//cFz03jIRVtYsBJVx57djeAKAS76NZPUq3mc+G/zUkYTJUJmOqBNeejSQ\n IeZiLpdn6RHL4Tmv50Cc4G9B34ASgg1/iyghRSrM9P2H9YjDinpRmKrAVrFCtr4Ua+0r\n RD5gife8Wy1XAzjAh4E4ZQoi0kvGDdRG42g6mLwz/1yn1Mpy0Ig25D0URKIROqiJ9pEa\n zKxirB4YsuOVii+RwtlTrItrFMIycg7R+1TivC5o4OTcNPrLAOgO0r0ehYmZ8BI6BX0r\n S8ezKp1vWX+5M2WvdaMUMsJvnW2dqeSYxfgD5BM++IrmSSZRBNjS+uRXKecYiZ8fee3Y\n a51g==","ARC-Message-Signature":"i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com;\n s=arc-20240605;\n h=cc:to:subject:message-id:date:from:in-reply-to:references\n :mime-version:dkim-signature;\n bh=4c3RvBiPkdPFC0fmjYbOCnMdf+5YT+BLcXXu5L75KQo=;\n fh=ZJtCY/Flzb2kIi63uVk8Xod53Hn2uNJF3rmZE9hGI7s=;\n b=gp0imiO16P/X2t3sJKazYBu0syEv43XkY6zZI3XbQfu1acBB6PWWL1yrsLxqfNE6hj\n e0ga1SEbmK4BCPr/0KVfZ3zGLWvo3mINhf9lDP+gBDMZCxNbLVdT1QvIzyXL3ts4BoJ+\n 6zKD51JtRKxIUONBA6dRsbBllG3MM1ZZBJqVaoNtWinrJsM41xYVwT7/dnrvvANFZ3LB\n wbZJ4kkD/GJje+F5OqNnVOf8osel6M56DtCe7Jna2PTEtUua0nTbEHXNbup9sewtAWdk\n QxHQ4sWuqYmi1xd1xq4SDeT9tSQaAFVfMiKIUJNsE5pTfk4MopgK3M5IKcQAitjU0F9z\n vnMw==; darn=lists.linux.it","ARC-Authentication-Results":"i=1; mx.google.com; arc=none","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n d=gmail.com; s=20251104; t=1776328848; x=1776933648; darn=lists.linux.it;\n h=cc:to:subject:message-id:date:from:in-reply-to:references\n :mime-version:from:to:cc:subject:date:message-id:reply-to;\n bh=4c3RvBiPkdPFC0fmjYbOCnMdf+5YT+BLcXXu5L75KQo=;\n b=WAYzjZNpg2l9qd6SwCux5da0o6DK2NF2CPhFOAZlEjCIh3ncA7CQ+tqIFfegrxGyeQ\n 4o6Fg8oT6j3Ycm6GUDMQhaxrHNUVMVEqjWNrlZPYWTsMe1r7IZPtglwe+515TJaqjhwY\n n2Pawnv6YcAvpD9oLjxiyE1xyXyNAvWGY5JKjKoIvBPraeEQLRNhFSsorMhqlEg1lo04\n N3LXkkMPiu57htZpSofF1SVGi123bEFkzSZg66u9Hyh6ubTlMEU/KMxUgkcjPkiPtVpn\n 0ZSzsvmPcV6kXBGCinquvi3n4unn+RYWmehnsAjqZ80SzoH66yp7Ddmh3uU+pn2qXyab\n Zpyg==","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n d=1e100.net; s=20251104; t=1776328848; x=1776933648;\n h=cc:to:subject:message-id:date:from:in-reply-to:references\n :mime-version:x-gm-gg:x-gm-message-state:from:to:cc:subject:date\n :message-id:reply-to;\n bh=4c3RvBiPkdPFC0fmjYbOCnMdf+5YT+BLcXXu5L75KQo=;\n b=Il9EMnbFYeuh+RCCy5y7KM+CygbmUOkrAxFuPtMPPI3RXTon9/ROuWDrcF3s6Tembk\n QONlRsuqPztrNLKtrAUMgfZrQAopQFbwZNyYZlajIQftxS3i0C0dgxA7hsuAg6eLsF7z\n 6tL6CTc9F+DqJ8CJcdg7EYDl+NvCxmwbmj32CRRrD4HQ3NjJPw0dPtHV9fE2sPPZSgR3\n qkNVYyOoR5ohWraxUS7l/WRApBNROv/xYyR5jwRtO+hTYz4/LFzmUtv0kvoRaJbjOMs9\n lRqmabwCXlcWLA6u740PMO3VLqMTz13lfRkPYI3AeKQrKLRJgzK9sivxzLJfaMd9ydQM\n 9PWA==","X-Forwarded-Encrypted":"i=1;\n AFNElJ97JsIktC/xp0DHSJs25wxHYkt1tLrE1pc1+fQpaTHuPgMeQHmZq8+weMQqElj7R2lq0/g=@lists.linux.it","X-Gm-Message-State":"AOJu0Yyq50C4XK+D4W2cXLRM+DDlBwHt5enRcozklgukmwElFmqt4c9N\n lAOg44vJDitdfTm0YqDea4yuI5qeG4DtivI2PUPpI+Ipx9I24+LL0WaZcYTXoMe/X4WllZyQCpt\n Stpi4i3apBUIzWRGoXttT0BZrJ9GSHg==","X-Gm-Gg":"AeBDietlhDzz2QmdPSl2FO0xQTwQ1Wbjr7uR6uDEjH+IOPePzx2udbC5iZ6cyRs/rZG\n 8AEIQGaMhhVBP7wAfB4TKoNYRf3qg8rV8XBed2II/psW/eKr68Wp2clnZ39PPClN6D8OM7XeQEK\n M3i3/eAYhalbwcXt5PfKvWPRtoXdlme1EHMdm54YgkL5XJ+B3KKqXocwzayz6pSleV0HAMBlCws\n Z8UQ1JJyyDC5wOcz6fPKdNuRYBytwyEkL/lcviGyjemtbCsZyGO1g+lM2WMh2z1WyT9PNI+bqGZ\n 2c9yNqHRrKrjvuO5uw/RYqVasWk=","X-Received":"by 2002:a05:622a:610c:b0:509:2b02:c1bd with SMTP id\n d75a77b69052e-50dd5b18f23mr364610521cf.12.1776328847748; Thu, 16 Apr 2026\n 01:40:47 -0700 (PDT)","MIME-Version":"1.0","References":"<53f26493-09fc-4f8b-9751-24d2c2e80697@linux.ibm.com>\n \n \n \n \n \n \n <17da2ea7-b1f8-49ab-95ed-30083592e7fa@linux.ibm.com>","In-Reply-To":"<17da2ea7-b1f8-49ab-95ed-30083592e7fa@linux.ibm.com>","From":"Li Wang ","Date":"Thu, 16 Apr 2026 16:40:36 +0800","X-Gm-Features":"AQROBzAojD5Xc9fz-lpyxpA3HAJsugbDGfdZwkIsbylVgqkkN8UTmny4wbtOByo","Message-ID":"\n ","To":"Soma Das ","X-Spam-Status":"No, score=0.1 required=7.0 tests=DKIM_SIGNED,DKIM_VALID,\n DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,SPF_HELO_NONE,SPF_PASS\n shortcircuit=no autolearn=disabled version=4.0.1","X-Spam-Checker-Version":"SpamAssassin 4.0.1 (2024-03-25) on in-7.smtp.seeweb.it","X-Virus-Scanned":"clamav-milter 1.0.9 at in-7.smtp.seeweb.it","X-Virus-Status":"Clean","Subject":"Re: [LTP] [PATCH] sched_football: fix false failures on many-CPU\n systems","X-BeenThere":"ltp@lists.linux.it","X-Mailman-Version":"2.1.29","Precedence":"list","List-Id":"Linux Test Project ","List-Unsubscribe":",\n ","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n ","Cc":"John Stultz , ltp@lists.linux.it","Content-Type":"text/plain; charset=\"us-ascii\"","Content-Transfer-Encoding":"7bit","Errors-To":"ltp-bounces+incoming=patchwork.ozlabs.org@lists.linux.it","Sender":"\"ltp\" "}}]