From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from canpmsgout09.his.huawei.com (canpmsgout09.his.huawei.com [113.46.200.224]) (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 66A14342539 for ; Wed, 29 Jul 2026 09:19:39 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=113.46.200.224 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785316784; cv=none; b=MU1+XV1Ydh4YSX/pzuvnPL0tvUDaTFohA39zd9bQyDEXmjzdPmnjiGw+p+ombHfYs136iiuE73fKvAZpuPjGYfhcB93v/pte0V8xuVAvV4FazOJmlQdt+6yFg7FacshregkUStNC8phE4mJkoGxW9HIbWmAquefmXncdVGblnqg= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785316784; c=relaxed/simple; bh=bgjt+615LP07VOrc8+Y53bbSC5+1GvcnRMDbD+ZHp6k=; h=Message-ID:Date:MIME-Version:Subject:To:CC:References:From: In-Reply-To:Content-Type; b=l/r8RfgyjbIOuOF9wX54JkTigM3MbpIaB1JFWJx/YQfqcwE5DblZLdgM89AIRc/4mHKm+BwW1Bu/28iFv1CapiRe5f3XK+BMilNbkMW2hYcfFqULvIluzB/PS2FVZtL+9w+XwYTygqiVSp/ymwRmjnTPQvSizeN9fS+6Q81uwkg= 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=oYAJh4Q1; arc=none smtp.client-ip=113.46.200.224 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="oYAJh4Q1" dkim-signature: v=1; a=rsa-sha256; d=huawei.com; s=dkim; c=relaxed/relaxed; q=dns/txt; h=From; bh=vfVAyNotT1Ix+GyHrYSfn7mPKgmRSFA8B3EIkOEd84A=; b=oYAJh4Q1trIdWax7p7UlSTUAE+rI03Kk2GehA2mDYuIZcbts6V+kUTd2+OKLVTmzrb2/3PRaF qPVvSkf+JZ1HRtWVqXhlrPfRpKpS7I6FM8s/jWep4ln5aEp5QGgeGCVOlgFx557u0bh8k7WRv6y kaLGAjvodeZFnFlHAATpeVI= Received: from mail.maildlp.com (unknown [172.19.163.214]) by canpmsgout09.his.huawei.com (SkyGuard) with ESMTPS id 4h96423ZW3z1cyTS; Wed, 29 Jul 2026 17:10:10 +0800 (CST) Received: from kwepemj100017.china.huawei.com (unknown [7.202.194.11]) by mail.maildlp.com (Postfix) with ESMTPS id 1484A4056C; Wed, 29 Jul 2026 17:19:36 +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, 29 Jul 2026 17:19:35 +0800 Message-ID: <8b7cd508-3b89-4fc0-85fd-5a8d35ed06ca@huawei.com> Date: Wed, 29 Jul 2026 17:19:34 +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 v8 1/2] sched/cache: Reduce the overhead of task_cache_work by only scan the visisted cpus Content-Language: en-US To: Chen Yu CC: "Chen, Yu C" , , , , , , , , , , , , References: <20260723040429.630176-1-luogengkun2@huawei.com> <20260723040429.630176-2-luogengkun2@huawei.com> <1dc03c84-9bc2-4db1-bab4-3f603fba54cd@huawei.com> From: Luo Gengkun In-Reply-To: Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-ClientProxiedBy: kwepems500001.china.huawei.com (7.221.188.70) To kwepemj100017.china.huawei.com (7.202.194.11) On 2026/7/28 20:08, Chen Yu wrote: > 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? What I am worried about is the following scenario: Thread A (CPU 0) Thread B (CPU 1) ================ ================ task_cache_work() | +-> try_cmpxchg() == true | (Sets next_scan = now + 10) | +-> Enters Scanning Loop (jiffies = 100) | [ Delayed / Preempted ] | jiffies advances 100 -> 115. | Thread A STILL in the loop! | task_cache_work() (jiffies = 115) | | | +-> next_scan == 110 (pass timeout check) | | | +-> try_cmpxchg() == true | | (Sets next_scan = 115 + 10) | | In other words, concurrent execution of task_cache_work() from two adjacent periods can occur under extreme conditions; do we need to take this scenario into consideration? Perhaps we need an explicit state flag (e.g., using test_and_set_bit) to ensure that the previous task_cache_work() execution has fully completed before allowing a new thread to proceed, regardless of whether the next scan window has arrived. What do you think? thanks, Gengkun > > thanks, > Chenyu