From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pl1-f175.google.com (mail-pl1-f175.google.com [209.85.214.175]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id ED7A22F46 for ; Tue, 7 Jan 2025 01:24:42 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.175 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1736213084; cv=none; b=IrJBZ/4t7ehf/dX4fea2G/CcHj4KpkJV9YgRejaP23IGv4uJ/o7sW4gbkpbuACrGXy59SU9/mjVUB8Nq7xMr0PhvXyJJNq5iWgI30E9vpLmijalvJgFHY+uKl8Sxoux1cvFOodwlIcmL/bkU4epdO3zBgg1pckXzo42q6ulHEkY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1736213084; c=relaxed/simple; bh=jcIsTExMB7JIqTFI4RT2vb0TadO+ldzB+yodukygqrE=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=P5gG6mB+zJMjZ95K9f8HXYKNc7qP1F8IR2eG1OKxkY962Zjjx98NALXzB066XGoIjl+t1LHK6oclih8981rKtpVIx2qHBTOqPu82wnoUiMO4d5DrhJ4ndavQWnIQF49r6hMdh9zqch02m0XLJH/x7Zil95nOduDoJjQdrw7cDIU= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=telus.net; spf=pass smtp.mailfrom=telus.net; dkim=pass (2048-bit key) header.d=telus.net header.i=@telus.net header.b=Xy3OlMh0; arc=none smtp.client-ip=209.85.214.175 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=telus.net Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=telus.net Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=telus.net header.i=@telus.net header.b="Xy3OlMh0" Received: by mail-pl1-f175.google.com with SMTP id d9443c01a7336-21634338cfdso22322265ad.2 for ; Mon, 06 Jan 2025 17:24:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telus.net; s=google; t=1736213082; x=1736817882; darn=vger.kernel.org; h=thread-index:content-language:content-transfer-encoding :mime-version:message-id:date:subject:in-reply-to:references:cc:to :from:from:to:cc:subject:date:message-id:reply-to; bh=IfjiYmQqDUZHrvRxIg3SlJdO7L3K1d9+GtT8Ze+AApY=; b=Xy3OlMh0LAf2vVOD9wIo1XSBkfO1VpypASjda7C0nvRtc/MKWqLv6Q+2d92EL8IhSX a4rfCotFTUB6ZpQjV6kBtm1kK0iXJLN8WfKoqBj9bN7GUiguKWWdEGHhf1XgYSvkzREt v4bgBgvCAXcLbRsRznWF8Nkc6TPY3KG66gwKkTm9762QsXqH2Xt8yEs9LaKcjIAYJpU8 O5Cn5Wo02rqn9cK8l7MCG9rFSBOyZsINEWRXrSstpo4RQehbYcpn3X7yxI9Vke3RIGCt 7toYZJmebVcJRx5qitpDbi7cORH0Wl4e09BAsJQeMg2tOkTA/PXTjTC2p/kdHrhof9j7 WEPA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1736213082; x=1736817882; h=thread-index:content-language:content-transfer-encoding :mime-version:message-id:date:subject:in-reply-to:references:cc:to :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=IfjiYmQqDUZHrvRxIg3SlJdO7L3K1d9+GtT8Ze+AApY=; b=f1n1PHa+k38CxlFraJQi/lXQAYzMjq3882qKnXEIW2FCseEWn1/8lDWVj2v8PiEE1T AAnSYMPy16TPOJSupQgKqE4CzAOVGcrceUoUvfS94SyC3i9uHUOyPNR2SOTUaOLrrw7o +mi9ITd2CPIT4p6hBBotLmD23UZGRTaVyVrY5nTA913VVWR298lF33WiNUcqw0c+duZe aNwQE/MYmn+Wz8q0QGzR/w4/GOAIW6DKS4NAoPvBj82ArNfNpSPVGcsy6HPWmODubz1a MS2noh79rE4MqKfgSAl5hcq4/PT1nVHvHsvOQZ2YOobSu2xk7q+SGgqsQmGNZtPeS8T+ d1LQ== X-Gm-Message-State: AOJu0YxZvJSOspw1qCP1Io3biHWsQNhRapCU/+7EaO+sJG5J2sdWnxQV Bv/+j7lMe3771yI0+RUCxkuIKaFlJXcYOEM4MM9Rk7kqMDsLm1Xa9h01IB8U5o3a/aljMxspcUI N X-Gm-Gg: ASbGncsq5gMJgC3f5k8c7pXcrZOn+ccSIMwCxfR18hXgsIPayYorMtcpDLWczObaza8 i/lC7yLVZbocgw5LHliCRbo5lQdehmV00C/Ug9qkqXJMN3s5YbW2UCEbdafBG9UXJFdT6qFzRb7 AaVmPP2Ju0W/zDavRZo0643Ui+5tjg4RqQ2bTC2kYEd8YlJ7sS1ymPBXG4xBiQfreUXEV6rjq5e vP9318VKFD6qHeu65Je4Un/s3n8HiYPtneAMRQggRwsIQ76JmgrP5y93GbqsWQgiFHnWdkrcrAZ aJVdgVBn8I97xhLDdKFHxw== X-Google-Smtp-Source: AGHT+IEeu+h9/MU3qHm/28aD2mcSLcdb+RSvgAGXqNAz5K8fkVvIqNulB/I+XBvwVrHNMzqVQXt7Lg== X-Received: by 2002:a17:903:120e:b0:215:6816:6345 with SMTP id d9443c01a7336-219e6ea278cmr862570665ad.16.1736213082264; Mon, 06 Jan 2025 17:24:42 -0800 (PST) Received: from DougS18 (s66-183-142-209.bc.hsia.telus.net. [66.183.142.209]) by smtp.gmail.com with ESMTPSA id 41be03b00d2f7-99ef9b82444sm3437197a12.17.2025.01.06.17.24.41 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 06 Jan 2025 17:24:41 -0800 (PST) From: "Doug Smythies" To: "'Peter Zijlstra'" Cc: , , "Doug Smythies" References: <005f01db5a44$3bb698e0$b323caa0$@telus.net> <20250106115732.GE20870@noisy.programming.kicks-ass.net> <000801db604b$e0f6b580$a2e42080$@telus.net> <20250106165932.GG20870@noisy.programming.kicks-ass.net> <20250106170455.GB22191@noisy.programming.kicks-ass.net> <20250106171402.GC22191@noisy.programming.kicks-ass.net> In-Reply-To: <20250106171402.GC22191@noisy.programming.kicks-ass.net> Subject: RE: [REGRESSION] Re: [PATCH 00/24] Complete EEVDF Date: Mon, 6 Jan 2025 17:24:44 -0800 Message-ID: <002701db60a2$ef760820$ce621860$@telus.net> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Content-Language: en-ca Thread-Index: AQJdvfVp9nqa9troPEySggPg+fzySgGTHC4vAVKdTGwBPBBbIAH1WJEKAdTgwICxxme0QA== On 2024.01.06 09:14 Peter Zijlstra wrote: > On Mon, Jan 06, 2025 at 06:04:55PM +0100, Peter Zijlstra wrote: >> On Mon, Jan 06, 2025 at 05:59:32PM +0100, Peter Zijlstra wrote: >>> On Mon, Jan 06, 2025 at 07:01:34AM -0800, Doug Smythies wrote: >>> >>>>> What is the easiest 100% load you're seeing this with? >>>> >>>> Lately, and specifically to be able to tell others, I have been using: >>>> >>>> yes > /dev/null & >>>> >>>> On my Intel i5-10600K, with 6 cores and 2 threads per core, 12 CPUs, >>>> I run 12 of those work loads. >>> >>> On my headless ivb-ep 2 sockets, 10 cores each and 2 threads per core, I >>> do: >>> >>> for ((i=0; i<40; i++)) ; do yes > /dev/null & done >>> tools/power/x86/turbostat/turbostat --quiet --Summary --show Busy%,Bzy_MHz,IRQ,PkgWatt,PkgTmp,TSC_MHz --interval 1 >>> >>> But no so far, nada :-( I've tried with full preemption and voluntary, >>> HZ=1000. >>> >> >> And just as I send this, I see these happen: >> >> 100.00 3100 2793 40302 71 195.22 >> 100.00 3100 2618 40459 72 183.58 >> 100.00 3100 2993 46215 71 209.21 >> 100.00 3100 2789 40467 71 195.19 >> 99.92 3100 2798 40589 71 195.76 >> 100.00 3100 2793 40397 72 195.46 >> ... >> 100.00 3100 2844 41906 71 199.43 >> 100.00 3100 2779 40468 71 194.51 >> 99.96 3100 2320 40933 71 163.23 >> 100.00 3100 3529 61823 72 245.70 >> 100.00 3100 2793 40493 72 195.45 >> 100.00 3100 2793 40462 72 195.56 >> >> They look like funny little blips. Nowhere near as bad as you had >> though. > > Anyway, given you've confirmed disabling DELAY_DEQUEUE fixes things, > could you perhaps try the below hackery for me? Its a bit of a wild > guess, but throw stuff at wall, see what sticks etc.. > > --- > diff --git a/kernel/sched/core.c b/kernel/sched/core.c > index 84902936a620..fa4b9891f93a 100644 > --- a/kernel/sched/core.c > +++ b/kernel/sched/core.c > @@ -3019,7 +3019,7 @@ static int affine_move_task(struct rq *rq, struct task_struct *p, struct rq_flag > } else { > > if (!is_migration_disabled(p)) { > - if (task_on_rq_queued(p)) > + if (task_on_rq_queued(p) && !p->se.sched_delayed) > rq = move_queued_task(rq, rf, p, dest_cpu); > > if (!pending->stop_pending) { > @@ -3776,28 +3776,30 @@ ttwu_do_activate(struct rq *rq, struct task_struct *p, int wake_flags, > */ > static int ttwu_runnable(struct task_struct *p, int wake_flags) > { > - struct rq_flags rf; > - struct rq *rq; > - int ret = 0; > + CLASS(__task_rq_lock, rq_guard)(p); > + struct rq *rq = rq_guard.rq; > > - rq = __task_rq_lock(p, &rf); > - if (task_on_rq_queued(p)) { > - update_rq_clock(rq); > - if (p->se.sched_delayed) > - enqueue_task(rq, p, ENQUEUE_NOCLOCK | ENQUEUE_DELAYED); > - if (!task_on_cpu(rq, p)) { > - /* > - * When on_rq && !on_cpu the task is preempted, see if > - * it should preempt the task that is current now. > - */ > - wakeup_preempt(rq, p, wake_flags); > + if (!task_on_rq_queued(p)) > + return 0; > + > + update_rq_clock(rq); > + if (p->se.sched_delayed) { > + int queue_flags = ENQUEUE_NOCLOCK | ENQUEUE_DELAYED; > + if (!is_cpu_allowed(p, cpu_of(rq))) { > + dequeue_task(rq, p, DEQUEUE_SLEEP | queue_flags); > + return 0; > } > - ttwu_do_wakeup(p); > - ret = 1; > + enqueue_task(rq, p, queue_flags); > } > - __task_rq_unlock(rq, &rf); > - > - return ret; > + if (!task_on_cpu(rq, p)) { > + /* > + * When on_rq && !on_cpu the task is preempted, see if > + * it should preempt the task that is current now. > + */ > + wakeup_preempt(rq, p, wake_flags); > + } > + ttwu_do_wakeup(p); > + return 1; > } > > #ifdef CONFIG_SMP > diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h > index 65fa64845d9f..b4c1f6c06c18 100644 > --- a/kernel/sched/sched.h > +++ b/kernel/sched/sched.h > @@ -1793,6 +1793,11 @@ task_rq_unlock(struct rq *rq, struct task_struct *p, struct rq_flags *rf) > raw_spin_unlock_irqrestore(&p->pi_lock, rf->flags); > } > > +DEFINE_LOCK_GUARD_1(__task_rq_lock, struct task_struct, > + _T->rq = __task_rq_lock(_T->lock, &_T->rf), > + __task_rq_unlock(_T->rq, &_T->rf), > + struct rq *rq; struct rq_flags rf) > + > DEFINE_LOCK_GUARD_1(task_rq_lock, struct task_struct, > _T->rq = task_rq_lock(_T->lock, &_T->rf), > task_rq_unlock(_T->rq, _T->lock, &_T->rf), I tried the patch on top of kernel 6.13-rc6. It did not fix the issue. I used my patched version of turbostat as per the previous email, so that I could see which CPU and the CPU migration time. CPU migration times >= 10 milliseconds are listed. Results: doug@s19:~date Mon Jan 6 04:37:58 PM PST 2025 doug@s19:~$ sudo ~/kernel/linux/tools/power/x86/turbostat/turbostat --quiet --show Busy%,IRQ,Time_Of_Day_Seconds,CPU,usec --interval 1 | grep -v \- | grep -e "^[1-9]" -e "^ [1-9]" -e "^ [1-9]" usec Time_Of_Day_Seconds CPU Busy% IRQ 16599 1736210307.324843 11 99.76 1004 6003601 1736210314.329844 11 99.76 1018 1164604 1736210330.509843 11 99.76 1003 6003604 1736210347.524844 11 99.76 1005 23602 1736210369.570843 11 99.76 1003 161680 1736210384.748843 7 99.76 1002 5750600 1736210398.507843 11 99.76 1005 6003607 1736210478.587844 11 99.76 1002 210645 1736210479.799843 3 99.76 7017 22602 1736210495.838843 11 99.76 1002 6003390 1736210520.861844 11 99.76 1002 108627 1736210534.984843 10 99.76 1002 23604 1736210570.047843 11 99.76 1003 6004604 1736210600.076843 11 99.76 1003 1895606 1736210606.977843 11 99.76 1002 3110603 1736210745.226843 11 99.76 1003 6003606 1736210765.244844 11 99.76 1002 6003605 1736210785.262843 11 99.76 1002 401642 1736210847.732843 9 99.76 1002 6003604 1736210891.781843 11 99.76 1003 6003607 1736210914.802844 11 99.76 1002 6003605 1736210945.831843 11 99.76 1002 5579609 1736210968.428848 11 99.76 1002 6003600 1736210975.433844 11 99.76 6585 93623 1736210985.537843 10 99.76 1003 5005605 1736210994.547843 11 99.76 1003 2654601 1736211029.244843 11 99.76 1004 17604 1736211057.290843 11 99.76 1003 23598 1736211077.334843 11 99.76 1006 114671 1736211079.451843 2 99.76 1003 6003603 1736211105.475843 11 99.76 1002 ^Cdoug@s19:~$ date Mon Jan 6 04:52:18 PM PST 2025 doug@s19:~$ uname -a Linux s19 6.13.0-rc6-peterz #1320 SMP PREEMPT_DYNAMIC Mon Jan 6 16:25:39 PST 2025 x86_64 x86_64 x86_64 GNU/Linux