From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from canpmsgout10.his.huawei.com (canpmsgout10.his.huawei.com [113.46.200.225]) (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 EB69E329C66 for ; Sat, 18 Apr 2026 09:02:03 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=113.46.200.225 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776502928; cv=none; b=feAm3hf9OFTMizE5Cd/u5R4d0cGWsxv66dnHUkCsJp/1GKXrre+g5lwFtMTe+XgVXNzb/yro49OUKoigLysnH9Qs1NxGvhc6nlXwflXSYNMWcj9nCbZksLQlmahDrdjpuCmWnrQR5ux8vSXVX+RPfgQhfcBhFel2UdIGfzPj86Y= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776502928; c=relaxed/simple; bh=PPUIkqwlg0+iudeWWR4wXHM6sJ230O+ifxuf7fsVNJw=; h=Message-ID:Date:MIME-Version:Subject:To:CC:References:From: In-Reply-To:Content-Type; b=LbyfA3zoH0YQL8G403de++yejfRxBChJuwGsdXzgtunWFqr++dc+JDH8BtTLKWoYPdAXa3eazf1vKLxVulLr0+yWVtdm/CUw+k+j5rA32KRLds1tg7tXl4C9EAD14fzHycJ2tJqpP5yaweQbtle7KWgOGL6/qbTtcxZ0iIhp2GA= 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=AWPGnOeh; arc=none smtp.client-ip=113.46.200.225 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="AWPGnOeh" dkim-signature: v=1; a=rsa-sha256; d=huawei.com; s=dkim; c=relaxed/relaxed; q=dns/txt; h=From; bh=ZNepu892kok+rAucQlTl2Z4wmucXmEFu4IQTqj9az6o=; b=AWPGnOeh9BvXFcGKlUkG5mlzm0ixQlW9ZrtJC+25ojaeE7IobcYw9CnEpBYPocGKLqlPzx8RW 2HBnTi61AQhxKpEhWOA49/fbrLYYYGUFVLacKnLIE0o66I+8HizOsApXb5BZzd4B2GO9mqioIWw b/nCI1TSFyeTh7MzVCK2NCA= Received: from mail.maildlp.com (unknown [172.19.163.15]) by canpmsgout10.his.huawei.com (SkyGuard) with ESMTPS id 4fyQZP6wNGz1K980; Sat, 18 Apr 2026 16:55:41 +0800 (CST) Received: from kwepemj100017.china.huawei.com (unknown [7.202.194.11]) by mail.maildlp.com (Postfix) with ESMTPS id D4E7340539; Sat, 18 Apr 2026 17:01:59 +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; Sat, 18 Apr 2026 17:01:58 +0800 Message-ID: <1be805ac-789e-4db4-b458-977f55901369@huawei.com> Date: Sat, 18 Apr 2026 17:01:58 +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 v2] sched/cache: Reduce the overhead of task_cache_work by only scan the visisted cpus. Content-Language: en-US To: "Chen, Yu C" CC: , , , , , , , , , , , , , , , , , , , , , , , , , , , , , References: <4fb7a6da-447d-452a-a920-7cd39b939ccb@intel.com> <20260414150745.225416-1-luogengkun2@huawei.com> <1ae149cd-7b36-4625-8e93-daf45aaac080@intel.com> From: Luo Gengkun In-Reply-To: <1ae149cd-7b36-4625-8e93-daf45aaac080@intel.com> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-ClientProxiedBy: kwepems200001.china.huawei.com (7.221.188.67) To kwepemj100017.china.huawei.com (7.202.194.11) On 2026/4/15 11:10, Chen, Yu C wrote: > Hi Gengkun, > > On 4/14/2026 11:07 PM, Luo Gengkun wrote: >> The overhead of task_cache_work is high, espeically in multi-NUMA system. >> Currently, task_cache_work try to find the pref_llc by scan all cpus in the >> system. However, most of these scans are meaningless, such as those for >> cpus that have never been visited or were accessed a long time ago. >> >> To address this problem, this patch introduces visited_cpus to track the >> visited cpus and uses llc_epoch_visited_timeout to evict cpus that have >> timed out. >> >> Signed-off-by: Luo Gengkun >> --- >> Thanks for the reviews. I've updated the patch based on your feedback. >> >> v2 Changes: >> 1. Added a pre-check before set/clear visited_cpus to avoid C2C overhead. >> 2. Optimized llc_epoch_visited_timeout by using a static key to minimize overhead. > > Since the visited CPUs optimization should help reduce the scan cost, > I wonder if we should enable it by default, regardless of the timeout > value set by the user. This mainly helps avoid introducing extra debugfs > controls/static key. I would be happy to do this. > >>   #ifdef CONFIG_PREEMPT_DYNAMIC >> @@ -669,6 +717,8 @@ static __init int sched_init_debug(void) >>       llc = debugfs_create_dir("llc_balancing", debugfs_sched); >>       debugfs_create_file("enabled", 0644, llc, NULL, >>                   &sched_cache_enable_fops); >> +    debugfs_create_file("epoch_visited_timeout", 0644, llc, NULL, >> +                &sched_cache_timeout_enable_fops); > > Is it possible to reuse llc_epoch_affinity_timeout without introducing > epoch_visited_timeout? The idea is that if a task has not run on that CPU > for 10 ms (by default), its footprint will be cleared. I think this is also acceptable, because visited_timeout is inspired by affinity_timeout. > > [ ... ] > >> @@ -1736,8 +1746,17 @@ static void task_cache_work(struct callback_head *work) >>                   continue; >>               for_each_cpu(i, sched_domain_span(sd)) { >> -                occ = fraction_mm_sched(cpu_rq(i), >> -                            per_cpu_ptr(mm->sc_stat.pcpu_sched, i)); >> +                struct rq *rq = cpu_rq(i); >> +                struct sched_cache_time *pcpu_sched = per_cpu_ptr(mm->sc_stat.pcpu_sched, i); >> +                /* Skip the rq that has not been hit for a long time */ >> +                if (sched_cache_timeout_enabled() && >> +                    cpumask_test_cpu(cpu_of(rq), &mm->sc_stat.visited_cpus) && > > cpumask_test_cpu(i) should be fine. The rq access above doesn't hold cpu_epoch_lock. > I wonder if we can safely calculate rq->cpu_epoch - pcpu_sched->epoch > inside fraction_mm_sched while holding the lock? Do we really need to access rq->cpu_epoch under the lock for read scenarios? I noticed task_tick_cache accesses it directly. Plus, moving this access outside the lock would help reduce lock contention. thanks, Luo Gengkun > > +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > I'll test your patch after fixing the bug reported by sashiko.dev. > +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > > thanks, > Chenyu > > > > >