From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from gentwo.org (gentwo.org [62.72.0.81]) (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 D2F5E34F498 for ; Wed, 22 Jul 2026 16:26:46 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=62.72.0.81 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784737608; cv=none; b=CXuhOTDFrmHaqO2NCdK4NujmS2xY7o3VICNGuXN70rjNSiBxDai4F4HQcm1zL/IjTuwehJg1Wm0rY/KnLS0jkr/l4SVS+KloGqpS3uXdEk7IJrgO208y05ZE7pV+Y4O7Rhn0X6rY51Ud8X51lUMeXK+hdsn3vTj85jfLzGFTWLA= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784737608; c=relaxed/simple; bh=JYlXYL5m8wFp+b2SKSatzVdlDeA5bxKaLh7O2umC/ts=; h=Date:From:To:cc:Subject:In-Reply-To:Message-ID:References: MIME-Version:Content-Type; b=bfQJNuLP//H/jtTZiTwprxPD1HajlhMIDK4eKIExdb8bNDvxD/SLdEAiqmoK8uEL6qx6PMOe5vzYAAZSwczTRdzO8gl/2oqm0W5dd32g45xfFO5daIh1KRSAo3MqFcHqUJjde4X5smvhbF1yTDpZvv8Y0w6tZXsYAY2E7NEVQx8= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=gentwo.org; spf=pass smtp.mailfrom=gentwo.org; dkim=pass (1024-bit key) header.d=gentwo.org header.i=@gentwo.org header.b=rBVOYW3m; arc=none smtp.client-ip=62.72.0.81 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=gentwo.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gentwo.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=gentwo.org header.i=@gentwo.org header.b="rBVOYW3m" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gentwo.org; s=default; t=1784737022; bh=JYlXYL5m8wFp+b2SKSatzVdlDeA5bxKaLh7O2umC/ts=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=rBVOYW3m6soAnScpztvfbgI0xQITgIAKZZAYP7F2ujzcpWg++kO5cZF836pPVBK3U tDA+vsxyQFOr3kVA4OR794o7bRby8w0ZoJ5nwmrlwruyeykPvxFOmBarNMIjz/bqBq wC9J9utDciGNcNOa+RhgWcNtwLbAqfEi1vJ+IPc4= Received: by gentwo.org (Postfix, from userid 1007) id D93D0402BC; Wed, 22 Jul 2026 09:17:02 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by gentwo.org (Postfix) with ESMTP id D6D4B401E1; Wed, 22 Jul 2026 09:17:02 -0700 (PDT) Date: Wed, 22 Jul 2026 09:17:02 -0700 (PDT) From: Shubhang To: K Prateek Nayak cc: Ingo Molnar , Peter Zijlstra , Juri Lelli , Vincent Guittot , Dietmar Eggemann , Steven Rostedt , Ben Segall , Mel Gorman , Valentin Schneider , Christoph Lameter , Shubhang Kaushik , linux-kernel@vger.kernel.org Subject: Re: [PATCH v3] sched/core: Preserve wake flags across queued wakeups In-Reply-To: <1bebcf2d-2325-4e11-bb5f-347a0ac10fcc@amd.com> Message-ID: <888ae543-2e09-e885-b18a-4c5d1d3f1697@gentwo.org> References: <20260721-b4-sched-ttwu-wake-flags-v3-1-07b92122bf28@gentwo.org> <1bebcf2d-2325-4e11-bb5f-347a0ac10fcc@amd.com> 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; format=flowed Hi Prateek, On Wed, 22 Jul 2026, K Prateek Nayak wrote: > Hello Shubhang, > > On 7/22/2026 12:24 PM, Shubhang Kaushik (Ampere) wrote: >> Changes in v3: >> - Use READ_ONCE()/WRITE_ONCE() for sched_remote_wakeup_flags. > > Why? Adding to the llist will have release semantics and I don't think > there is any way for the receiver to see an object on the llist and it > not having "sched_remote_wakeup_flags" set properly. > > Otherwise, a bunch of csd initialization bits would also need > READ_ONCE() / WRITE_ONCE() but I don't see any. Thanks, that makes sense. I added READ_ONCE()/WRITE_ONCE() because the field is written by the waking CPU and read by the target CPU, so I initially treated it as an explicit cross-CPU field. But the flags are stored before the task is published with llist_add(), and the target CPU reads them only after removing the entry from the llist. So yeah, will drop that. >> --- a/include/linux/sched.h >> +++ b/include/linux/sched.h >> @@ -983,6 +983,16 @@ struct task_struct { >> >> /* Used for emulating ABI behavior of previous Linux versions: */ >> unsigned int personality; >> + /* >> + * Must not share the scheduler bitfield word because wakelist >> + * queueing is not serialized by p->on_cpu. >> + * >> + * smp_load_acquire(&p->on_cpu) in ttwu_queue_wakelist() pairs > > This should be "before" and not "in" here ^^ > >> + * with smp_mb__after_spinlock() in schedule(), making current's > > What? That load acquire pairs with smp_store_release() in finish_task() > before interrupts are enabled after context-switch on the destination > CPU. > Agreed, will fix this comment. >> diff --git a/kernel/sched/core.c b/kernel/sched/core.c >> index 96226707c2f6135341aa779b8262f113e103d8ad..7ddcc6a7f1c06675ce8084cd304475d61f869eb7 100644 >> --- a/kernel/sched/core.c >> +++ b/kernel/sched/core.c >> @@ -3902,13 +3902,16 @@ void sched_ttwu_pending(void *arg) >> update_rq_clock(rq); >> >> llist_for_each_entry_safe(p, t, llist, wake_entry.llist) { >> + int wake_flags; > > Do we really need that local variable? > No, once READ_ONCE() goes away this can be passed directly to ttwu_do_activate(). I'll drop the local variable as well. >> @@ -3947,11 +3950,14 @@ bool call_function_single_prep_ipi(int cpu) >> * via sched_ttwu_wakeup() for activation so the wakee incurs the cost >> * of the wakeup instead of the waker. >> */ >> +#define WF_TTWU_QUEUE_MASK (WF_TTWU | WF_SYNC | WF_MIGRATED | \ >> + WF_RQ_SELECTED) > > I much rather prefer it in single line even though it crosses > 80 characters. #defines like SCHED_DL_FLAGS run even longer. Sure, will keep it in one line. >> static void __ttwu_queue_wakelist(struct task_struct *p, int cpu, int wake_flags) >> { >> struct rq *rq = cpu_rq(cpu); >> >> - p->sched_remote_wakeup = !!(wake_flags & WF_MIGRATED); >> + WRITE_ONCE(p->sched_remote_wakeup_flags, >> + wake_flags & WF_TTWU_QUEUE_MASK); >> >> WRITE_ONCE(rq->ttwu_pending, 1); >> #ifdef CONFIG_SMP > > FWIW, feel free to include: > > Tested-by: K Prateek Nayak Thanks, I'll add it. Regards, Shubhang Kaushik