From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mta1.migadu.com (out-62.mta1.migadu.com [95.215.58.62]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id B2A9034A794 for ; Wed, 19 Aug 2026 01:55:23 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=95.215.58.62 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787104525; cv=none; b=KfSab9Taa641qgAGe6x+71lnNHqZBXt6YXOnWZQkJPg5Cz3pGOyasgWS4mU/y6Lugqetx3DQcurTo4L/plFnTBleUV8TTuuhsXegerNABncVddlZU0cn/BENUpAYJmdEtGLBKfnXMd8C5bfm212S3r6qIQcOtKGspV/YzMygAwc= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787104525; c=relaxed/simple; bh=cpjSziAa1QWsebCg8X2khZdcgAgtgosPRo76uTwvxEE=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=sbVoX0OExnpdc3K6z939Yr8iDdNxTKWtJflWlhbZnrY4YHP8FYxyWpDMOxOEwMMHbPmxGLtQ6iNEofJGPXlMiY+m+Tcli3DGG3Lope3M2T73MgZDA0lQrPUaigRdS0qXQ2I1i4EiScd6PPLXdeywloYUnzqzqMUSqv1PLw8+81c= 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=Vlwdm8Yh; arc=none smtp.client-ip=95.215.58.62 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="Vlwdm8Yh" X-Envelope-To: linux-kernel@vger.kernel.org DKIM-Signature: a=rsa-sha256; bh=cpjSziAa1QWsebCg8X2khZdcgAgtgosPRo76uTwvxEE=; c=simple/simple; d=linux.dev; h=from:to:subject:date:message-id:mime-version:content-type; s=key1; t=1787104521; v=1; x=1787709321; b=Vlwdm8Yh+PqEUzqCuUlJWdMTNkkYSykqPv/uqRvVyOVb9pxKOpDmhf6u5tjcLVSTx1sPjvLe K+9V6E+W8Dczxp7M+xse1nY0Xy9ZXbRVKV+EokW7pW7qglf5RBq7zJxJcIXrpkpwckccwTkbyUl /9KelDzBZLpcmVkgIUSiAOrI= X-Envelope-To: linux-kernel@vger.kernel.org Received: from [10.22.64.46] (118.201.124.118) by smtp.migadu.com with ESMTPS id 86b40ab8aa26f951; Wed, 19 Aug 2026 01:55:11 +0000 X-Migadu-Flow: FLOW_OUT Message-ID: <581a7675-61e3-4418-8a98-e2ba6e3c6d81@linux.dev> Date: Wed, 19 Aug 2026 09:55:07 +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] mm: add cond_resched() to free_pud_range() To: Mike Rapoport Cc: linux-mm@kvack.org, Andrew Morton , David Hildenbrand , Lorenzo Stoakes , "Liam R . Howlett" , Vlastimil Babka , Suren Baghdasaryan , Michal Hocko , linux-kernel@vger.kernel.org, Lance Yang References: <20260818134934.92354-1-leon.hwang@linux.dev> Content-Language: en-US From: Leon Hwang In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 18/8/26 22:09, Mike Rapoport wrote: > On Tue, Aug 18, 2026 at 09:49:34PM +0800, Leon Hwang wrote: >> Packet receive timeouts were seen in production. Tracing showed that an >> exiting process with a sparse 2.5 TiB mapping could remain in kernel >> context for over 20 ms without reaching a scheduling point while >> freeing PTE page-table pages. Hard IRQs could still be handled, but the >> per-CPU ksoftirqd thread and other runnable tasks could not run during >> that interval, delaying NET_RX softirq work queued to ksoftirqd. >> >> Like zap_pud_range(), add cond_resched() to free_pud_range() so >> ksoftirqd and other runnable tasks can run between PUD entries. Testing >> with PREEMPT_NONE showed that the maximum interval between scheduling >> points fell from over 20 ms to below 2 ms. >> >> Reported-by: Lance Yang >> Tested-by: Lance Yang >> Signed-off-by: Leon Hwang >> --- >> mm/memory.c | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/mm/memory.c b/mm/memory.c >> index 4134ac607ee0..68c15449de07 100644 >> --- a/mm/memory.c >> +++ b/mm/memory.c >> @@ -231,7 +231,7 @@ static inline void free_pud_range(struct mmu_gather *tlb, p4d_t *p4d, >> if (pud_none_or_clear_bad(pud)) >> continue; >> free_pmd_range(tlb, pud, addr, next, floor, ceiling); >> - } while (pud++, addr = next, addr != end); >> + } while (pud++, cond_resched(), addr = next, addr != end); > > This is really obscure, can't it be in the loop body? Agreed. It should be in the loop body, after free_pmd_range(). Thanks, Leon >> >> start &= P4D_MASK; >> if (start < floor) >> -- >> 2.55.0 >> >> >