From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mx0a-001b2d01.pphosted.com (mx0a-001b2d01.pphosted.com [148.163.156.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 4D99D389467 for ; Thu, 8 Jan 2026 10:02:16 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=148.163.156.1 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1767866540; cv=none; b=LMrvT3tMbi5oFy/54H+BsCLmmdh4JEJVWV9VyW2McTLgitKj/PCf67uWoQH0q5UL1+DByimq7uY73gOeROY1DQV5Dqhrom1V0woLn7GytRBHgCF0ygeJz+/lgqVjtsYM/kbnvWJAXAEZGdqedgjrHeX1d1Xo7Kk8TGrNSK9g60M= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1767866540; c=relaxed/simple; bh=v3E2rprXF6238wGAQke3n9Yy3r063BVEab8pbdhCHBg=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=iQV92vaMF13+Zbr4H5Yvqnxho47wBKtvRudr1gvQiqPN7nF88KDerekJG3TAl31ihAUCPBTvpkMBDWpaPZ44tPgkNr0/g6zVmGz7ct4A/Epncaod9VBN3fhBQylwsX+gKsDkW9IUV4R5992ecwT/wLUM+gMGwGY2MNSjMFDvAEQ= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.ibm.com; spf=pass smtp.mailfrom=linux.ibm.com; dkim=pass (2048-bit key) header.d=ibm.com header.i=@ibm.com header.b=TfQIJanz; arc=none smtp.client-ip=148.163.156.1 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.ibm.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.ibm.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=ibm.com header.i=@ibm.com header.b="TfQIJanz" Received: from pps.filterd (m0360083.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.18.1.2/8.18.1.2) with ESMTP id 607N7XaN004343; Thu, 8 Jan 2026 10:01:59 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ibm.com; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to; s=pp1; bh=zkEA+Q uJzOkYcNbqLs5VJgMLPMo6MUpMAr197pxFNn8=; b=TfQIJanzM+ez3pplUOBk25 YGj47Y6h5rxcWd7vSigmaSisU6v+Ypn8cqctqtoR7vxhf5adBqi6lmHa0/IIIBwW jo3bIn/cQI18oR6YhUZuOv8JtB9ZB2j3Nd8X6As8x8B2hLfAnhieKxVI/vTLPmih G9EBfU4XXN8AgCaH76Axs5e+IWhrbxTc+IEPcxvXQ2LOERlBmNqdvozbyTznjTCG m2ddscqnKJ2FgWWD5lm8QlQqEbSW+D+jFNlxubcfpwBAMf6AZVnHrM4/1QoZw6EP M+o7UUOfPdNTYSfze6Gaxolkd5VXDJVplgGwj/BXbnOviq+PvXKVoOMwr79jEcRg == Received: from ppma22.wdc07v.mail.ibm.com (5c.69.3da9.ip4.static.sl-reverse.com [169.61.105.92]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 4betm7dnx2-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 08 Jan 2026 10:01:58 +0000 (GMT) Received: from pps.filterd (ppma22.wdc07v.mail.ibm.com [127.0.0.1]) by ppma22.wdc07v.mail.ibm.com (8.18.1.2/8.18.1.2) with ESMTP id 6088OpZf023501; Thu, 8 Jan 2026 10:01:57 GMT Received: from smtprelay05.wdc07v.mail.ibm.com ([172.16.1.72]) by ppma22.wdc07v.mail.ibm.com (PPS) with ESMTPS id 4bg3rmjuw6-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 08 Jan 2026 10:01:57 +0000 Received: from smtpav04.dal12v.mail.ibm.com (smtpav04.dal12v.mail.ibm.com [10.241.53.103]) by smtprelay05.wdc07v.mail.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 608A1v3b26411706 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 8 Jan 2026 10:01:57 GMT Received: from smtpav04.dal12v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id F32705805A; Thu, 8 Jan 2026 10:01:56 +0000 (GMT) Received: from smtpav04.dal12v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 50BF458056; Thu, 8 Jan 2026 10:01:54 +0000 (GMT) Received: from [9.98.110.226] (unknown [9.98.110.226]) by smtpav04.dal12v.mail.ibm.com (Postfix) with ESMTP; Thu, 8 Jan 2026 10:01:53 +0000 (GMT) Message-ID: Date: Thu, 8 Jan 2026 15:31:52 +0530 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [REGRESSION] [PATCH 0/2 v5] Reintroduce NEXT_BUDDY for EEVDF To: Mel Gorman , Peter Zijlstra Cc: Ingo Molnar , Juri Lelli , Dietmar Eggemann , Valentin Schneider , Chris Mason , linux-kernel@vger.kernel.org, Madadi Vineeth Reddy References: <20251112122521.1331238-1-mgorman@techsingularity.net> Content-Language: en-US From: Madadi Vineeth Reddy In-Reply-To: <20251112122521.1331238-1-mgorman@techsingularity.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-TM-AS-GCONF: 00 X-Authority-Analysis: v=2.4 cv=OdmVzxTY c=1 sm=1 tr=0 ts=695f8096 cx=c_pps a=5BHTudwdYE3Te8bg5FgnPg==:117 a=5BHTudwdYE3Te8bg5FgnPg==:17 a=IkcTkHD0fZMA:10 a=vUbySO9Y5rIA:10 a=VkNPw1HP01LnGYTKEx00:22 a=VwQbUJbxAAAA:8 a=VnNF1IyMAAAA:8 a=vpAXdRWA9ABZBimrYp8A:9 a=QEXdDO2ut3YA:10 X-Proofpoint-GUID: FpkwZhNrwlu_1Oo86FaqrVDXN90BQ6nA X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYwMTA4MDA2NSBTYWx0ZWRfX2E0/Vq5nThxv G/TAefz07kCOExQe6SeZUnd06nBLjYnbv4RIL6FevKn5fgEMKJ2ORM1EEge6dSbikP2C8IR4/jq ICMcizIqkWlo/FLCMdsxTMJeCU7sZwpYZ4lXNnGp5IyTbomXfBCwOjs6nHhMVSYB+7soU0BOnHC J/ETfzgsAHuU9r24GC6tIKc3Ei/P7NIJhtvGRQi7oD3UhlSU7kspV5VM2frKqTjYmLdswDzdUBt FBuniAsoKB5/pWgIRfmnutdRpNgjg50wqUuoYuf17YW3HftPZa2rBMdu5lagn9Ew1wHqskP28gy QkGwuj+prNDgoXx4j0yh9x+MXkyiznvLQ6sqhjPiQ0vRtYfs1qTvh0s7eZi5bjIzMKdQpELhcl+ b6byypG6Z7Bb8NYztCRqWovsC5t9s6glna6JOMAvJGKqhA6umjTajS6+3Fy3/lq2FY8tWt+4aKN sOepGBnGcP3ZM5KUmkQ== X-Proofpoint-ORIG-GUID: FpkwZhNrwlu_1Oo86FaqrVDXN90BQ6nA X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1121,Hydra:6.1.9,FMLib:17.12.100.49 definitions=2026-01-08_02,2026-01-07_03,2025-10-01_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 clxscore=1015 phishscore=0 malwarescore=0 adultscore=0 lowpriorityscore=0 priorityscore=1501 impostorscore=0 bulkscore=0 suspectscore=0 classifier=typeunknown authscore=0 authtc= authcc= route=outbound adjust=0 reason=mlx scancount=1 engine=8.19.0-2512120000 definitions=main-2601080065 On 12/11/25 17:55, Mel Gorman wrote: > Changes since v4 > o Splitout decisions into separate functions (peterz) > o Flow clarity (peterz) > > Changes since v3 > o Place new code near first consumer (peterz) > o Separate between PREEMPT_SHORT and NEXT_BUDDY (peterz) > o Naming and code flow clarity (peterz) > o Restore slice protection (peterz) > > Changes since v2 > o Review feedback applied from Prateek > > I've been chasing down a number of schedule issues recently like many > others and found they were broadly grouped as > > 1. Failure to boost CPU frequency with powersave/ondemand governors > 2. Processors entering idle states that are too deep > 3. Differences in wakeup latencies for wakeup-intensive workloads > > Adding topology into account means that there is a lot of machine-specific > behaviour which may explain why some discussions recently have reproduction > problems. Nevertheless, the removal of LAST_BUDDY and NEXT_BUDDY being > disabled has an impact on wakeup latencies. > > This series enables NEXT_BUDDY and may select a wakee if it's eligible to > run even though other unrelated tasks may have an earlier deadline. > > Mel Gorman (2): > sched/fair: Enable scheduler feature NEXT_BUDDY > sched/fair: Reimplement NEXT_BUDDY to align with EEVDF goals > > kernel/sched/fair.c | 152 ++++++++++++++++++++++++++++++++++------ > kernel/sched/features.h | 2 +- > 2 files changed, 131 insertions(+), 23 deletions(-) > Hi Mel, Peter, During internal testing, I noticed approximately 7% regression in a real-world workload called DayTrader. Git bisect pointed to this patch: "sched/fair: Reimplement NEXT_BUDDY to align with EEVDF goals" Before this patch was merged, I reported a regression in v4 with schbench and stress-ng. >From that discussion: https://lore.kernel.org/all/ddfde793-ad6e-4517-96b8-662dcb78acc8@linux.ibm.com/#t ``` So with frequent wakeups, queued tasks (even with earlier deadlines) may be unfairly delayed. I understand that this would fade away quickly as the woken up task that got to run due to buddy preference would accumulate negative lag and would not be eligible to run again, but the starvation could be higher if wakeups are very high. To test this, I ran schbench (many message and worker threads) together with stress-ng (CPU-bound), and observed stress-ng's bogo-ops throughput dropped by around 64%. This shows a significant regression for CPU-bound tasks under heavy wakeup loads. ``` I understand that stress-ng bogo-ops is not a reliable metric. However, the problem appears to be real, as DayTrader also shows regression with this patch. To check if WF_SYNC related change is the issue, I tried to decrease threshold by `echo 50000 > /sys/kernel/debug/sched/migration_cost_ns` so that waker could preempt quickly in WF_SYNC case. This helped but I understand that it changes a lot of code paths that use migration_cost_ns. So, when I decreased only threshold in this patch, the performance didn't improve. So, I think the problem is in making the tasks that are having earlier deadline to wait in presence of frequent wakeups is hurting CPU intensive workloads. Any thoughts/ideas? Meanwhile, I will also spend time to workaround this patch and see if the performance could be improved. Thanks, Vineeth