From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.9]) (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 0CE67418A39 for ; Tue, 14 Jul 2026 22:40:29 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.9 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784068836; cv=none; b=F6zPu5YXYRAtFs7VcB8iiKsYp3kqQOOlW7K7xC/O/Fhdb3Kt8T3K0XGzq50/I52xaERC9XdwaGYZDewFcezjT6PTPETJcMqjHFN2WHoQboUPOPDlhL7ep3nuEd8XyW5veiU9BmRqIGxHYVyeUSuf0mZSRj+5wnsea+Su9Ob1SEQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784068836; c=relaxed/simple; bh=8xorAVtaukXK+L/lbNHwn5DlILfZQ4CIcCeV5FIz7vI=; h=Message-ID:Subject:From:To:Cc:Date:In-Reply-To:References: Content-Type:MIME-Version; b=BR48Shw7FN4slg/x9+ID2FRwsFHmIq6E0N1D34JZmSdRpMfXlG/OzM6mlG2B1srIuNPF2WELAYH5t1R/fquHHsNjbz8SAADWf506tj7paQ4HtBJDgdp/U4WJHHeaf1BZmNI6AgcArSpOAxSQnCdeMrdceAD95Sh8AUUm8mLOIsE= 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=g3m4Kbn6; arc=none smtp.client-ip=192.198.163.9 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="g3m4Kbn6" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1784068830; x=1815604830; h=message-id:subject:from:to:cc:date:in-reply-to: references:content-transfer-encoding:mime-version; bh=8xorAVtaukXK+L/lbNHwn5DlILfZQ4CIcCeV5FIz7vI=; b=g3m4Kbn60hRgVCrbO1kzPxQ0GeiJId7V53uhpl2NL/lLSnzFwh4QvoB5 MjVzGlOq07MiL/05efBwN8Kob5jvJftVav993Bbj+hXqpp6Vl+ZKwCvUL 8zNA0bjm9pWXpz3skdgYZ19UksdlND1O8hSlbSx94Tvi4+bUI3jY3H020 auXx1y4OvmmYzIXXCczuvkQ6MC8xbCCblvXzMlbcTweDLEm4f1yXz6TgH YBl6mNxEzIQBXwQf51VjOmX8jwXb3qKo227s2EbmsqVodWXc7BEH06MHX C1kZVBB8jZes1I+LaZ96Gl3wIuka8BK+ROdNdbf6PxCtYChQdqLoKaOzI g==; X-CSE-ConnectionGUID: OdQwCfzVTP2WpDUMsbiS+w== X-CSE-MsgGUID: lkNUcxAjT9uqRF0bO+eIiA== X-IronPort-AV: E=McAfee;i="6800,10657,11847"; a="95347567" X-IronPort-AV: E=Sophos;i="6.25,164,1779174000"; d="scan'208";a="95347567" Received: from orviesa009.jf.intel.com ([10.64.159.149]) by fmvoesa103.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 14 Jul 2026 15:40:29 -0700 X-CSE-ConnectionGUID: hRnItMGUSbKJhNt0Y7HxSw== X-CSE-MsgGUID: 1gAPVb7nSsyUaWVzxNXGxQ== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.25,164,1779174000"; d="scan'208";a="256635584" Received: from unknown (HELO [10.241.243.185]) ([10.241.243.185]) by orviesa009-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 14 Jul 2026 15:40:28 -0700 Message-ID: <95dc124ed604ff568dc01ba502adf8d4e35c255b.camel@linux.intel.com> Subject: Re: [PATCH v5 1/2] sched/cache: Reduce the overhead of task_cache_work by only scan the visisted cpus From: Tim Chen To: "Chen, Yu C" , Luo Gengkun Cc: dietmar.eggemann@arm.com, rostedt@goodmis.org, bsegall@google.com, mgorman@suse.de, peterz@infradead.org, vschneid@redhat.com, kprateek.nayak@amd.com, linux-kernel@vger.kernel.org, juri.lelli@redhat.com, mingo@redhat.com, vincent.guittot@linaro.org, "chen.yu@linux.dev" Date: Tue, 14 Jul 2026 15:40:21 -0700 In-Reply-To: References: <20260709130053.2749834-1-luogengkun2@huawei.com> <20260709130053.2749834-2-luogengkun2@huawei.com> 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-07-09 at 23:01 +0800, Chen, Yu C wrote: > Hi Gengkun, >=20 > thanks for the update, >=20 > On 7/9/2026 9:00 PM, Luo Gengkun wrote: >=20 > > +static unsigned long fraction_mm_sched(int cpu, > > + struct mm_struct *mm) > > { > > + struct sched_cache_time *pcpu_sched =3D > > + per_cpu_ptr(mm->sc_stat.pcpu_sched, cpu); > > + struct rq *rq =3D cpu_rq(cpu); > > + > > guard(raw_spinlock_irqsave)(&rq->cpu_epoch_lock); > > =20 > > + /* Skip the rq that has not been hit for a long time */ > > + if ((rq->cpu_epoch - pcpu_sched->epoch_timeout) > llc_epoch_affinity_= timeout) { > > + cpumask_clear_cpu(cpu, &mm->sc_stat.visited_cpus); > > + return 0; > > + } > > + >=20 > I was wondering if there is a race condition in the scenario > above: If the rq has just updated its cpu_epoch field, and the > CPU subsequently remains idle, then rq->cpu_epoch stays unchanged. > That is to say, a race could occur as follows: if CPU1 becomes idle, > CPU2's task_cache_work() might compute > rq->cpu_epoch - pcpu_sched->epoch_timeout =3D=3D 0 and consequently fail > to clear CPU1 from visit_cpus. >=20 > CPU_1 CPU_2 > ------------------------------------ -------------------------------= -- > account_mm_sched(rq_X) > set CPU1 in visited_cpus >=20 >=20 > (idle: fair task runs here, > CPU1.cpu_epoch frozen afterwards, > pcpu_sched->epoch_timeout =3D CPU1.epoch) > fraction_mm_sched() > CPU1->cpu_epoch -=20 > pcpu_sched->epoch_timeout =3D 0 > -> bit CPU1 not cleared > __update_mm_sched()=20 > ->update cpu_epoch, too late > I wonder if we should let __update_mm_sched() be invoked before > if ((rq->cpu_epoch - pcpu_sched->epoch_timeout) >=20 > llc_epoch_affinity_timeout)? Also, I am not sure why we need to create this new field pcpu_sched->epoch_= timeout? Wouldn't rq->cpu_epoch - pcpu_sched->epoch give the elapsed epochs since the last time that cpu was visited for this mm (as in __update_mm_sched())?=C2=A0 There are some races possible when cpu_epoch changes before the whole accounting got done. A CPU could get visited after you think that it hasn't got visited. But you will also have race if you use epoch_timeout.=20 Tim =20 >=20 > BTW, in your test data: > sched_cache_scan: comm=3Dredis-server pid=3D24660 scan=3D384 > Is it because NUMA balancing is disabled on your platform that it has > to scan all the CPUs? It would be helpful to know what the result would > be with NUMA balancing enabled. > I found some reports from sashiko here that are worth taking a look at: > https://sashiko.dev/#/patchset/20260709130053.2749834-1-luogengkun2%40hua= wei.com >=20 > thanks, > Chenyu >=20