From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from canpmsgout07.his.huawei.com (canpmsgout07.his.huawei.com [113.46.200.222]) (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 EA74337DE81 for ; Fri, 10 Apr 2026 10:20:15 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=113.46.200.222 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775816418; cv=none; b=gUOd5maQ1PGpkullnn3oumCEPbix1jFxpy/HlHEUzVro+0BRbAyhxCG9bUypJ6j/Xit0lb3C30yxm9zkddSvNLM3OfJTUeNZszl1ysy1QFsBxEdpAMwWS7eEOdVn2ATto8WCI5AcGBTVMFX3e/BzeD6r92m3sHQ5mxE9lOKJGRw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775816418; c=relaxed/simple; bh=PqFWA8s4InGRxRbIDtu3VQFrA1ikZ5daL75PfUacL9c=; h=Message-ID:Date:MIME-Version:Subject:To:CC:References:From: In-Reply-To:Content-Type; b=cXAm6gLDf1/ZVPhSI3BhF/LZkSdSDl5l973uOORxiOHU8XfF2s4aXa0E0O+S00Jdo04nzLYnfQWacijtFMjHRWtfDahe1fS7XhOcTLhI9YAFWuH+j2i/91L77ah18zbdFHe45L7UG/rU3akNbOPtNcAkLtz8SIUl+g7gLKC7LO8= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=huawei.com; spf=pass smtp.mailfrom=huawei.com; dkim=pass (1024-bit key) header.d=huawei.com header.i=@huawei.com header.b=nnXL/sk/; arc=none smtp.client-ip=113.46.200.222 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=huawei.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=huawei.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=huawei.com header.i=@huawei.com header.b="nnXL/sk/" dkim-signature: v=1; a=rsa-sha256; d=huawei.com; s=dkim; c=relaxed/relaxed; q=dns/txt; h=From; bh=f9Lx8Yr5Snv0doi3WMhh8A5mNejn6sFZCWUn29I0YVs=; b=nnXL/sk/0rOqFuPis/WEkEFsGEgkawTmLElCM6eQg5oBKD/41Qr0c60ofh+6PYCNt/0zKa2DH IzIzoWIDpoictEAq7DVPa4Mi8hIUAuNRe1np7NUZA9Evo5fxlHZ2/WJwIM6kJqqE5FD3KmKIBVZ 09CoEVZfdoFn0thlOxH+TGY= Received: from mail.maildlp.com (unknown [172.19.163.163]) by canpmsgout07.his.huawei.com (SkyGuard) with ESMTPS id 4fsXhQ6nvvzLlVQ; Fri, 10 Apr 2026 18:13:58 +0800 (CST) Received: from kwepemj100017.china.huawei.com (unknown [7.202.194.11]) by mail.maildlp.com (Postfix) with ESMTPS id 7A9074048B; Fri, 10 Apr 2026 18:20:13 +0800 (CST) Received: from [10.67.108.244] (10.67.108.244) by kwepemj100017.china.huawei.com (7.202.194.11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.36; Fri, 10 Apr 2026 18:20:12 +0800 Message-ID: <338c2d51-6958-4cda-880a-270822f915ec@huawei.com> Date: Fri, 10 Apr 2026 18:20:11 +0800 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [Patch v4 02/22] sched/cache: Limit the scan number of CPUs when calculating task occupancy Content-Language: en-US To: "Chen, Yu C" CC: Peter Zijlstra , Tim Chen , K Prateek Nayak , Ingo Molnar , 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 , Adam Li , Aaron Lu , Tim Chen , Josh Don , Gavin Guo , Qais Yousef , Libo Chen , References: <57ed5fcec9b242803fe4ea2ce6e7f3de6a6efc6b.1775065312.git.tim.c.chen@linux.intel.com> From: Luo Gengkun In-Reply-To: Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-ClientProxiedBy: kwepems500002.china.huawei.com (7.221.188.17) To kwepemj100017.china.huawei.com (7.202.194.11) On 2026/4/10 15:29, Chen, Yu C wrote: > Hi Gengkun, > > On 4/9/2026 9:17 PM, Luo Gengkun wrote: >> >> >> On 2026/4/2 5:52, Tim Chen wrote: >>> From: Chen Yu > > [ ... ] > >> >> To address the issue of scanning overhead, there is a more targeted approach: only scanning the CPUs actually accessed by the process, and evicting these CPUs when they remain unaccessed for a specific period of time. >> > > Thanks for the patch. This approach looks quite sensible to me, and > > [ ... ] > >> >>          /* >>           * The update to mm->sc_stat should not be reordered >> @@ -1582,6 +1584,7 @@ void account_mm_sched(struct rq *rq, struct task_struct *p, s64 delta_exec) >>                  pcpu_sched->runtime += delta_exec; >>                  rq->cpu_runtime += delta_exec; >>                  epoch = rq->cpu_epoch; >> +               cpumask_set_cpu(cpu_of(rq), &mm->sc_stat.visited_cpus); > > I would refer a check before writing to avoid c2c overhead: >     if (!cpumask_test_cpu(cpu_of(rq), &mm->sc_stat.visited_cpus)) >         cpumask_set_cpu(cpu_of(rq), &mm->sc_stat.visited_cpus); > >>          } >> >> >>          /* >> @@ -1724,7 +1727,10 @@ static void task_cache_work(struct callback_head *work) >>                  return; >> >> >>          scoped_guard (cpus_read_lock) { >> -               get_scan_cpumasks(cpus, p); >> +               if (unlikely(llc_epoch_visited_timeout == 0)) >> +                       get_scan_cpumasks(cpus, p); >> +               else >> +                       cpumask_and(cpus, cpu_online_mask, &mm-  >sc_stat.visited_cpus); >> > > I believe this patch will bring significant benefits(reduce jitter) > whenthe thread count is low, since it skips many CPUs. The only concern > is the frequency of reading and writing the "global" mm->sc_stat.visited_cpus > from multiple threads. However, if Peter's sbm can be leveraged in the future, This is a problem, maybe a per-cpu version can help to avoid this problem. I'll try writing one. > this  overhead should be further reduced. Anyway, let me run tests on our > machines to seethe results. Much appreciated! > > thanks, > Chenyu > > > >