From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out-188.mta1.migadu.com (out-188.mta1.migadu.com [95.215.58.188]) (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 7EFFF42D77C for ; Tue, 28 Jul 2026 12:09:00 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=95.215.58.188 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785240543; cv=none; b=nL/zAKFCWOu55Go0dELB+unM+eUyXIt39wrAjVFf7NLJRMYXpnD3ltrIl89WvPXxENDIBrpbARc0hv1H0AA02SrxOFqyAFuK6ZPkgfTiPNKcXDbra9CINo3ug2rN6jhyVy8F3pZm2iY50XXqppURSXdQmPLnBa3oLlP1KnW2aqE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785240543; c=relaxed/simple; bh=hQbxj+sDhldEFdVJlMa4muumZn0GPYuEoaceCTcFibk=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=WcIWlA6a/9vXFj484VDK5Ed7p2Y/GzqEPSOtTAZ+zJKysqifBxTqTuIk+BQh5AHm0/H86wApC34Z9sj0Ytw+I7l7lB2mttBbUQN6+QLvXdq5NHOYnWBmfhU9KySzv3QWCv1xxHjvr0ujPHBZHZ2ZfVLgf2/v5ws+lVaNkG/NSsY= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev; spf=pass smtp.mailfrom=linux.dev; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b=izkmHcWt; arc=none smtp.client-ip=95.215.58.188 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.dev Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b="izkmHcWt" Date: Tue, 28 Jul 2026 20:08:36 +0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1785240538; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=aWMDN2YyHgyCqMVU7z4qdl4Dp+4hEt9AwpuuZIgfj+o=; b=izkmHcWtq7bR7J1txIzwelNtjCih//WiAsk9NeiwYkBGR4WACJygnvqRcN9grB0/R5QolQ IOchaaG9TrT3KB3MWJVwb9fhvmky9bzz8IRqJksE9T89OeZ9ZsszWsrMznO1t74M3N4zhe i9BifUfOBZPWf64A+Dshpb/KP6WlNPs= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Chen Yu To: Luo Gengkun Cc: "Chen, Yu C" , tim.c.chen@linux.intel.com, dietmar.eggemann@arm.com, rostedt@goodmis.org, peterz@infradead.org, bsegall@google.com, mgorman@suse.de, vschneid@redhat.com, kprateek.nayak@amd.com, linux-kernel@vger.kernel.org, mingo@redhat.com, juri.lelli@redhat.com, vincent.guittot@linaro.org Subject: Re: : [PATCH v8 1/2] sched/cache: Reduce the overhead of task_cache_work by only scan the visisted cpus Message-ID: References: <20260723040429.630176-1-luogengkun2@huawei.com> <20260723040429.630176-2-luogengkun2@huawei.com> <1dc03c84-9bc2-4db1-bab4-3f603fba54cd@huawei.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=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1dc03c84-9bc2-4db1-bab4-3f603fba54cd@huawei.com> X-Migadu-Flow: FLOW_OUT On Tue, Jul 28, 2026 at 04:53:59PM +0800, Luo Gengkun wrote: > > On 2026/7/27 9:09, Chen, Yu C wrote: > > On 7/23/2026 12:04 PM, Luo Gengkun wrote: > > > > [ ... ] > > > > >       guard(raw_spinlock_irqsave)(&rq->cpu_epoch_lock); > > >       __update_mm_sched(rq, pcpu_sched); > > > +    /* Skip the rq that has not been hit for a long time */ > > > +    if ((rq->cpu_epoch - pcpu_sched->epoch_last_visit) > llc_epoch_affinity_timeout) { > > > > In v2 there is a check if the cpu has been set before writing: > > cpumask_test_cpu(cpu_of(rq), &mm->sc_stat.visited_cpus) > > https://lore.kernel.org/all/20260414150745.225416-1-luogengkun2@huawei.com/ > > do we need to bring that back? > > > I don't think we need it back. Here is why: > > In v2, for_each_cpu was used instead of for_each_cpu_and in the inner loop, > meaning some CPUs being checked might not have been set. Therefore, > cpumask_test_cpu was necessary to filter out those cases. > > Now, with for_each_cpu_and(i, sched_domain_span(sd), &mm->sc_stat.visited_cpus), > we can ensure each scanned CPU is set, so the issue no longer exists. > Furthermore, the only place where the visited_cpus bits are cleared is > task_cache_work(), which is only called once per scan period, there is no > risk of the bit being cleared concurrently mid-loop. > Make sense. > However, is there a possibility that the current task_cache_work() execution > hasn't finished yet when the next scan window arrives? For instance, if the > current task work is heavily delayed or preempted by unexpected interrupt, > jiffies could advance past next_scan before the loop completes. > If we move the `work->next = work;` to the very end of task_cache_work(), > would that resolve this issue? By doing so, the existing `work->next == work` > check in task_tick_cache() should fail and no new task work will be submitted. > > Please let me know if I'm missing something. > There are two layers of protection: first a cheap timeout gate (time_before) that skips scanning until the next period, and then a try_cmpxchg that atomically picks a single winner among the threads that pass the timeout — this actually guarantees only one scanner per mm at a time, no? thanks, Chenyu