From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.11]) (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 6D20A4C9579 for ; Tue, 21 Jul 2026 14:59:14 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.11 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784645956; cv=none; b=JXKX2C/nfV80+TMB5GipBE+lW/4L5Tu6GXmmH/xHUv+LsW8hM14UTFxQi+jq7IDVJNNbRbLirN8AmKOyNzBCAkmWNtKUqKm6wFafFXR0BFCpfO4rz6AG9UF5t/5uAH8fDGh7Ps8Np8w0fzjBwL5VhLy8Sw3JC2J+tADwixVHVS4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784645956; c=relaxed/simple; bh=Xey45W7AfwCBkiH//ScJToZsNY7dOV/6aKaDuTA5F+Q=; h=Message-ID:Subject:From:To:Cc:Date:In-Reply-To:References: Content-Type:MIME-Version; b=cV2c1wePrC2aq3MoP88r/tI9leAGwUnvLekRhTxIyW21yDKm9znhSSQN9MkCId0dwsuMQB9tB7McSaMyAg7H3C3pxamyR26FEii8TY9JPl8DiVJJtITXImVovroVRcFE9YHqKhBqDyktyLNh1SguhC7YZsBqC8WecBSL3MwzGv4= 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=Z3q3fnIs; arc=none smtp.client-ip=192.198.163.11 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="Z3q3fnIs" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1784645954; x=1816181954; h=message-id:subject:from:to:cc:date:in-reply-to: references:content-transfer-encoding:mime-version; bh=Xey45W7AfwCBkiH//ScJToZsNY7dOV/6aKaDuTA5F+Q=; b=Z3q3fnIsMJz0Cm0JdwC7oz3bFWtYUUbhS1gUYJ6mOY7sqK7gJN5RrbxN COeMxYAJBPaizwVuJzlt7ONd3/Gku/o9CWgTRpMUpcVtEvIVnw46lXxEO PAu1OVvJOayDk4Z97rjZREs92qFupfmYNeZzMmCYB4ySl5q9EqexkeouR uGPzn6YFR9L5jDpeqRfNhvrVijMdKpEJq6gHD1+NgtmTiYxUhwhSssGbE TyPzGIJ8/wjVDhMUmmuvPlVnDp0jM/jl576eVEwFejLc9tZteZKlq3F5s fhSNfSN4lJ+oyTJes7QIj9A9NTaRgiXa7vIaUNZZfkLwwxCkUXt8gxlaC g==; X-CSE-ConnectionGUID: Uq81S+uqR02veMoI7TcCuQ== X-CSE-MsgGUID: S6jeFJaTRFuPKpQ9dPUuTg== X-IronPort-AV: E=McAfee;i="6800,10657,11853"; a="95844332" X-IronPort-AV: E=Sophos;i="6.25,176,1779174000"; d="scan'208";a="95844332" Received: from orviesa005.jf.intel.com ([10.64.159.145]) by fmvoesa105.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 21 Jul 2026 07:59:13 -0700 X-CSE-ConnectionGUID: hgOtEQTBQnCAc1q/Pdraiw== X-CSE-MsgGUID: ogVltBW4RISUODtSBb2JYA== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.25,176,1779174000"; d="scan'208";a="262064585" Received: from schen9-mobl4.amr.corp.intel.com (HELO [10.125.109.217]) ([10.125.109.217]) by orviesa005-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 21 Jul 2026 07:59:13 -0700 Message-ID: Subject: Re: [PATCH v7 linux 1/2] sched/cache: Reduce the overhead of task_cache_work by only scan the visisted cpus From: Tim Chen To: Luo Gengkun , peterz@infradead.org, mingo@redhat.com, juri.lelli@redhat.com, vincent.guittot@linaro.org, yu.c.chen@intel.com Cc: dietmar.eggemann@arm.com, rostedt@goodmis.org, bsegall@google.com, mgorman@suse.de, vschneid@redhat.com, kprateek.nayak@amd.com, linux-kernel@vger.kernel.org Date: Tue, 21 Jul 2026 07:59:12 -0700 In-Reply-To: References: <20260720122214.3977092-1-luogengkun2@huawei.com> <20260720122214.3977092-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 Tue, 2026-07-21 at 10:53 +0800, Luo Gengkun wrote: >=20 >=20 snip > > > -static unsigned long fraction_mm_sched(struct rq *rq, > > > - struct sched_cache_time *pcpu_sched) > > > +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 > > > __update_mm_sched(rq, pcpu_sched); > > > =20 > > > + /* Skip the rq that has not been hit for a long time */ > > > + if ((rq->cpu_epoch - pcpu_sched->epoch_last_visit) > llc_epoch_affi= nity_timeout) { > > > + cpumask_clear_cpu(cpu, mm->sc_stat.visited_cpus); > > > + return 0; > > > + } > > > + > > > /* > > > * Runtime is a geometric series (r=3D0.5) and as such will sum to= twice > > > * the accumulation period, this means the multiplcation here shou= ld > > > @@ -1711,6 +1722,9 @@ void account_mm_sched(struct rq *rq, struct tas= k_struct *p, s64 delta_exec) > > > pcpu_sched->runtime +=3D delta_exec; > > > rq->cpu_runtime +=3D delta_exec; > > > epoch =3D rq->cpu_epoch; > > > + pcpu_sched->epoch_last_visit =3D epoch; > >=20 > > We need to make sure that the epoch_last_visit update is seen by the cp= u > > running task_cache_work(), before it attempts to do the epoch compariso= n > > and clear the cpu, and causing inconsistency in the visited_cpus. > >=20 > > For example > >=20 > > CPU A (e.g. doing LLC/affinity selection, reading remote pcpu_sched) = CPU B (=3D `cpu`, running account_mm_sched() locally) > > -------------------------------------------------------------------- = ----------------------------------------------------- > > read pcpu_sched->epoch_last_visit (stale, old value) > > -> looks like it timed out > > = pcpu_sched->epoch_last_visit =3D epoch (fresh visit!) > > = cpumask_set_cpu(cpu, visited_cpus) (correctly marks it visited) > > cpumask_clear_cpu(cpu, visited_cpus) <-- wipes out the fresh set! > >=20 > I don't think such a race condition will occur, because both the read and= clear > operations in fraction_mm_sched() are protected by rq->cpu_epoch_lock, ju= st like > account_mm_sched(). Please let me know if I'm missing something. >=20 Yes, the epoch lock should prevent the above race from happening. Missed that on my end. >=20 Thanks. Tim