From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.20]) (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 AB358261B8D for ; Thu, 9 Apr 2026 19:22:00 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.175.65.20 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775762522; cv=none; b=EUJyJvspgd+om2hFXzgYWTwwO51I+REpO2LkFinJ6Z1xhTtppJ9SjyvrtLh0BaEWjh693TG6sd3IkU0BpWhQPX2ouuJoNnmGf/a+/mL32KJMefU4zUCcoJlBhmVy2mhcIhydPuPs4G/AB8ciPAcxeXqCQIULl+G0tnkEehbobn8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775762522; c=relaxed/simple; bh=Ee7mbqsdtVksf1/BAZVvNSVpW8JcSihvnn83OidhD3Q=; h=Message-ID:Subject:From:To:Cc:Date:In-Reply-To:References: Content-Type:MIME-Version; b=DvcD1pUdOpS8bx5J3ZwBWoVPncuxTrKz/sSNQZ3c9vpz6EEt9KAEHVc4eZSlp7zjgRNDT7912swOjC7Il0ePgKXEdWZ1rdRlPPL2pwLh+LGtkQstr1ka64ueK8njdqfLW+wy8zD6iZ2yYR0r1I+aGPxc3Tq13hLFrNIs7RLOHuM= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com; spf=pass smtp.mailfrom=linux.intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=eMuOb7oc; arc=none smtp.client-ip=198.175.65.20 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="eMuOb7oc" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1775762521; x=1807298521; h=message-id:subject:from:to:cc:date:in-reply-to: references:content-transfer-encoding:mime-version; bh=Ee7mbqsdtVksf1/BAZVvNSVpW8JcSihvnn83OidhD3Q=; b=eMuOb7ocdjsWKkS1N2IYIsT+Cdh8ehvX64RmffLMGs7lUZBeIJMcu2p0 h9UPzTNDsWOev7v62ye6IDFS8lOGqOM/m4Bk+NIymI9YJ/m1qGpe5Wr7a 6G/CDwATd240lUDvJ6A9XnrqK7JRMHGHuDhdqXMYRjMlU2eW0L2E/rs+7 IZqjJhqjVqdHyTSjmePoU4ULkJIjU2vkTGATWnTM04Eydt99DIu27P2dU Rfcn7Y8u6k1PEg8S8oQb77+e4UIAiDDTZ8d/R9VLLJnRb2GQIjd+2KYPg lAIaxi5Cu5PGX3Aq7pJYi1GcAtdkOyZ2ANc9bMCQHUwzZQq3wJdEKUpYQ Q==; X-CSE-ConnectionGUID: ZlVzCkZsSfCz8QVWwLmB2w== X-CSE-MsgGUID: 1XhsSpgHRVa4ATv62lwWxg== X-IronPort-AV: E=McAfee;i="6800,10657,11754"; a="76496327" X-IronPort-AV: E=Sophos;i="6.23,170,1770624000"; d="scan'208";a="76496327" Received: from orviesa009.jf.intel.com ([10.64.159.149]) by orvoesa112.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 09 Apr 2026 12:21:59 -0700 X-CSE-ConnectionGUID: ecoJaPHwQoqlgDrCpCL+zg== X-CSE-MsgGUID: Id0oJp2AQkarDTgC3rgHZA== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.23,170,1770624000"; d="scan'208";a="228749035" Received: from unknown (HELO [10.241.243.39]) ([10.241.243.39]) by orviesa009-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 09 Apr 2026 12:21:59 -0700 Message-ID: <71b4ddab042b805a225eef92b0a9404b20aa2b98.camel@linux.intel.com> Subject: Re: [Patch v4 01/22] sched/cache: Introduce infrastructure for cache-aware load balancing From: Tim Chen To: Peter Zijlstra Cc: Ingo Molnar , K Prateek Nayak , "Gautham R . Shenoy" , Vincent Guittot , Juri Lelli , Dietmar Eggemann , Steven Rostedt , Ben Segall , Mel Gorman , Valentin Schneider , Madadi Vineeth Reddy , Hillf Danton , Shrikanth Hegde , Jianyong Wu , Yangyu Chen , Tingyin Duan , Vern Hao , Vern Hao , Len Brown , Aubrey Li , Zhao Liu , Chen Yu , Chen Yu , Adam Li , Aaron Lu , Tim Chen , Josh Don , Gavin Guo , Qais Yousef , Libo Chen , linux-kernel@vger.kernel.org Date: Thu, 09 Apr 2026 12:21:58 -0700 In-Reply-To: <20260409124110.GA3126523@noisy.programming.kicks-ass.net> References: <6269a53221b9439b9ca00d18a9d1946fb64d8cff.1775065312.git.tim.c.chen@linux.intel.com> <20260409124110.GA3126523@noisy.programming.kicks-ass.net> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.58.1 (3.58.1-1.fc43) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 On Thu, 2026-04-09 at 14:41 +0200, Peter Zijlstra wrote: > On Wed, Apr 01, 2026 at 02:52:13PM -0700, Tim Chen wrote: > > +static inline > > +void account_mm_sched(struct rq *rq, struct task_struct *p, s64 delta_= exec) > > +{ > > + struct sched_cache_time *pcpu_sched; > > + struct mm_struct *mm =3D p->mm; > > + unsigned long epoch; > > + > > + if (!sched_cache_enabled()) > > + return; > > + > > + if (p->sched_class !=3D &fair_sched_class) > > + return; > > + /* > > + * init_task, kthreads and user thread created > > + * by user_mode_thread() don't have mm. > > + */ > > + if (!mm || !mm->sc_stat.pcpu_sched) > > + return; > > + > > + pcpu_sched =3D per_cpu_ptr(p->mm->sc_stat.pcpu_sched, cpu_of(rq)); > > + > > + scoped_guard (raw_spinlock, &rq->cpu_epoch_lock) { > > + __update_mm_sched(rq, pcpu_sched); > > + pcpu_sched->runtime +=3D delta_exec; > > + rq->cpu_runtime +=3D delta_exec; > > + epoch =3D rq->cpu_epoch; > > + } > > + > > + /* > > + * If this process hasn't hit task_cache_work() for a while, or it > > + * has only 1 thread, invalidate its preferred state. > > + */ > > + if (time_after(epoch, > > + READ_ONCE(mm->sc_stat.epoch) + EPOCH_LLC_AFFINITY_TIMEOUT) || >=20 > I really think that: >=20 > if (epoch - READ_ONCE(mm->sc_stat.epoch) > EPOCH_LLC_AFFINITY_TIMEOUT) Sure. We can change it. >=20 > is simpler to read. >=20 >=20 > > + get_nr_threads(p) <=3D 1) { >=20 > And this, I just noticed this, why are we excluding tasks with one > thread? The comment just states we are (doh), but utterly fails to > explain why. The thought was that for a single thread, we will tend to place it in same LLC as it was previously running with cache hot. Incurring the added cost of tracking its residency in LLC is uneeded. Tim >=20 > > + if (mm->sc_stat.cpu !=3D -1) > > + mm->sc_stat.cpu =3D -1; > > + } > > +}