From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from canpmsgout03.his.huawei.com (canpmsgout03.his.huawei.com [113.46.200.218]) (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 9558E38C415 for ; Wed, 12 Aug 2026 09:03:05 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=113.46.200.218 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786525390; cv=none; b=Ei/Z5JsaiSJFTPz6SYuajfu3ytbAgQMcjvyBxTWFDcIJXoiALhzHl7wl0Z3WGQlnrOxfJiapEdcM7Dw6U+SGv1yzmN3CVNsndAmUdVliMp/rg77ybxnGT7j/kLArgE+7pzpwmmWCEi9rLd+zU+VxjdCu4c5RA/N6NyR0xa13NMI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786525390; c=relaxed/simple; bh=DrO+YaHrrkU1ZOcDl3QxF7IXePifuPA6Y9AIue6GdxY=; h=Message-ID:Date:MIME-Version:Subject:To:CC:References:From: In-Reply-To:Content-Type; b=bXTZPc9D6VqBA88kq88XlQppNUwRmkz5FulQndbf+4K/NA2dyRqWa/AvPs4mY+Z1JSlVn5/zq1gcr6ILUsu/gUagvaQKPxqlQi8PG+1tL77pSEqdJFacmhP/iFjfiglI9u1W9yVHKJQff2xwrHKn18vkJUzH5+O/t5lstiqFzVo= 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=tnWjdSY8; arc=none smtp.client-ip=113.46.200.218 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="tnWjdSY8" dkim-signature: v=1; a=rsa-sha256; d=huawei.com; s=dkim; c=relaxed/relaxed; q=dns/txt; h=From; bh=iGAibdok2ctMkhAO4clILfvgzTSfpTDI/8lEzqGba5g=; b=tnWjdSY8aXZ26fMY7cHx1Uq5gf8sX/oimXl9CEHJYl/LLP2ki9ljaOvVC+PxPhPYGoPepkvgl pyg3JHn1ECEJYlGVFt33MFE2l5cAlxJR0pUDNwwoNFJd6BaPoLnZ9GRUWeFZKxKtPpg1bXMFp5R yIqLrNcM0+5T4S3JHqh3cNg= Received: from mail.maildlp.com (unknown [172.19.162.223]) by canpmsgout03.his.huawei.com (SkyGuard) with ESMTPS id 4hKj0y2jxPzpSvb; Wed, 12 Aug 2026 16:52:18 +0800 (CST) Received: from kwepemj100017.china.huawei.com (unknown [7.202.194.11]) by mail.maildlp.com (Postfix) with ESMTPS id EA4DD40575; Wed, 12 Aug 2026 17:03:01 +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; Wed, 12 Aug 2026 17:03:01 +0800 Message-ID: <228dff06-1cf1-413e-a1db-0aefda384479@huawei.com> Date: Wed, 12 Aug 2026 17:03:00 +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 v9 1/2] sched/cache: Reduce the overhead of task_cache_work by only scan the visisted cpus Content-Language: en-US To: "Chen, Yu C" CC: , , , , , , , , , , , , "chen.yu@linux.dev" , Jianyong Wu References: <20260731024417.1106503-1-luogengkun2@huawei.com> <20260731024417.1106503-2-luogengkun2@huawei.com> <9fae7258-5f33-4ddc-8d21-599db3c0d091@intel.com> From: Luo Gengkun In-Reply-To: <9fae7258-5f33-4ddc-8d21-599db3c0d091@intel.com> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-ClientProxiedBy: kwepems100002.china.huawei.com (7.221.188.206) To kwepemj100017.china.huawei.com (7.202.194.11) On 2026/8/11 15:46, Chen, Yu C wrote: > Hi Gengkun, > On 8/11/2026 10:27 AM, Luo Gengkun wrote: > > I did a further study on this and have two minor questions: > >>> @@ -1711,6 +1722,9 @@ 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; >>> +        pcpu_sched->epoch_last_visit = epoch; >>> +        if (!cpumask_test_cpu(cpu_of(rq), mm->sc_stat.visited_cpus)) >>> +            cpumask_set_cpu(cpu_of(rq), mm->sc_stat.visited_cpus); > > visited_cpus bits are only cleared inside fraction_mm_sched(), which is > reachable in task_cache_work() - but that loop is skipped when invalid_llc_nr() > returns true for any single-threaded process. As a result, single-threaded > processes keep setting bits in account_mm_sched() without using them. > Maybe a gate would be useful: From a technical perspective, adding a gate here is unnecessary. The overhead is virtually nonexistent, especially since it resides on a path already burdened by heavier operations like __update_mm_sched(). If we were to care about performance and optimization, focusing on __update_mm_sched() would be far more meaningful than adding checks here. What do you think? > > if (get_nr_threads(p) > 1 && >     !cpumask_test_cpu(cpu_of(rq), mm->sc_stat.visited_cpus)) >     cpumask_set_cpu(cpu_of(rq), mm->sc_stat.visited_cpus); > > > [ ... ] > >>> @@ -1866,7 +1835,18 @@ static void task_cache_work(struct callback_head *work) >>>       scoped_guard (cpus_read_lock) { >>>           guard(rcu)(); >>> -        get_scan_cpumasks(cpus, p); > > I'm thinking of if this could bring cross-node bouncing. Is it doable > to honor the result from NUMA preference: >     get_scan_cpumasks(cpus, p); >     cpumask_and(cpus, cpus, mm->sc_stat.visited_cpus); I looked closely at get_scan_cpumasks(). The CPU mask it returns is the union of node(p->numa_preferred_nid), node(mm->sc_stat.cpu), and node(task_cpu(p)). Its purpose was only to mitigate sc_stat.cpu bouncing — it did not fully eliminate it. Relying on visited_cpus alone follows the actual footprint of where the threads really ran, making it even less prone to bouncing. Additionally, even if the numa node derived from visited_cpus disagrees with a given thread's numa_preferred_nid, get_pref_llc() still prevents that thread from being migrated to that node, so it remains safe either way. Please let me know if I'm missing something. thanks, Gengkun > > thanks, > Chenyu >