From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wr1-f54.google.com (mail-wr1-f54.google.com [209.85.221.54]) (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 32FF924BBF0 for ; Wed, 19 Aug 2026 06:53:25 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.54 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787122407; cv=none; b=aU0Ud6/H30VdlzaHS0X6KLRVnDckHntV0OCzlfAwZ8Co/GcCC94PdEbBPEJKvMUnaa7VXow73lRbUzf3zd7HT9qOAbl9GpX+HvoHLeoYWJ3aSk827i1rvJCEDdmOoCLBHtooF0UN247QtjPdgUExszliUIrfJlqsEpKHk6kjeIw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787122407; c=relaxed/simple; bh=OBCsm+WRl4YSgb/k4kizlvfi1NSGsF+sunpAH5J9zjc=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=gtXTxgldU6sG6hy4ycz9c35aaoAfMb1oNaMZqJ821weAqNSBt46keC7gSjWDUv9wl1Lp0N5l6HJO1FIa/13eToPO9hmZuUcqCkrsDrUlEY0uFnvdnWSzJ73R7tv1f1Cm/lH/HU+NpqsMCcRAcGarpaJ+O0ZcyPhiwtWL/ytHs9c= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=suse.com; spf=pass smtp.mailfrom=suse.com; dkim=pass (2048-bit key) header.d=suse.com header.i=@suse.com header.b=B/K7mhYm; arc=none smtp.client-ip=209.85.221.54 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=suse.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=suse.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=suse.com header.i=@suse.com header.b="B/K7mhYm" Received: by mail-wr1-f54.google.com with SMTP id ffacd0b85a97d-47ddf7b09e5so620890f8f.1 for ; Tue, 18 Aug 2026 23:53:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1787122403; x=1787727203; darn=vger.kernel.org; h=in-reply-to:content-disposition:content-type:mime-version :references:message-id:subject:cc:to:from:date:from:to:cc:subject :date:message-id:reply-to:content-type; bh=oBQIpuMPNnnZS9TxQr2cmt0QezkZP8hh1DGqeV86S60=; b=B/K7mhYm4ohBPhy+WX5EyRWVIvdNCN1KVBfalq4v+8lxDwysZkNZQkf8REOzKiqzvo BoPGg3pdNm76L6o3g9P/pISzQPgYwIF05mJ6jeOH9dN3C/6CNP/Pbv/zPaZOVwILFsbc Dk7j4SHAKeiUda1Q7arWaiDW0RVWQD/eq0Huqb5dxg5IA9bRlSAySViwycmKXO2CLy2c 8aF8rqbiYgRMo2dbvOynCaGLTSkkrccTeURcpCrE/CA4d6nrnKr52d/xGYB6CIdaqtmx BopBx5djRTjCmk6FA5+jtsHpEnmND16FMWWwQEQDjX9OUnsx9LtTrOraati7GijTLRow 6UnA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1787122403; x=1787727203; h=in-reply-to:content-disposition:content-type:mime-version :references:message-id:subject:cc:to:from:date:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=oBQIpuMPNnnZS9TxQr2cmt0QezkZP8hh1DGqeV86S60=; b=SqOAx4M9hXNGhW5R0B5PkE49/o/knfokq8W5I/XKgV9seHY6VQgLOnSqfYOcWyIlXN DKcKMlfFNzII1Xa9fyDMQMwG9WDA+Fne0O8O4FqbLdmwTwBlKkrCaCK0VHnqVzRKjyGI 29KqSTXbqHcl82au0sLdV9T+mrCczeokmWSk5GYBJd+TJNT/QrnGe8J9s4stF/jHJSns Bhc62wUx6h2upSgFyXX1NOGSTU3LD5BE4FchCdXdcUGCJzXXVDXk7baqicLeGVua5Zsd 35FaHvT/TprGqEnz3Llv5FN8YgtnUwNz4hWSiv7XKW2RLOQDtJZgvW5qF/RH088Ga9IJ ePUA== X-Forwarded-Encrypted: i=1; AHgh+RqZ5HOSKgx0Hy82Y6WhCxUwvp4fUiyz0o0MANEov+cImzy+pWGsCg/18jH8XWf1+1LEUiwZGkvgo6M4b8c=@vger.kernel.org X-Gm-Message-State: AOJu0YygoE27rnUsoTMU7BsaA9kNNY0dH4q3QT7V4iMV8klqcMT74o8A F7fKPYTNo5Jjoj8UijoID9/m+Dk9EEKtFOdYK5ZDEMtSRWahqXRzB4NNelt+b/mHIWk= X-Gm-Gg: AR+sD13/1wxDncAW7l7F2yxlHe7cF2xLs69rg4L7Ea5YFRT0RSsD1wGppeNjF/EjtP6 Z62Aye9BHTON0KCJhM3o/O5kyt/AjzgJCchlodK45YO5DgD8/FL2dv46X7PyQ32uQt6mq9vImT5 hyulkmNNxvDespkdcxDXuTYINDE+m2dTQGkja5enr2tEctAm7Cp7bKN5VcouFxwohTcWjHSQ6az g+JnMK+dItk5cBnymT1xfBW19u6RLbFwbFRxMpzVwZuJQD7pMQDFIOU6F/93N9/+RD6VuBV+6mA 8EzUJn5TcrhtzQbIzQnNxcBkM5QoECklalHlbsCn5i9+Yhvc46DxcVxxXNLTh1XdUHTg8fKjUse +nZYohgR20AZMl3wA4Pe1aOlaK33hlqzzhdQrIvmn8jr/q0zk+TuqZzt/r57W09rC5epldy+yBJ vksucdf3OAuSplSSEmPvoRgrjQsHObR/+5bis1MKhSUgrsH4EDZjqJ79X25xf6txpyIwbFPpYPb A== X-Received: by 2002:a05:6000:41da:b0:47f:9557:8d77 with SMTP id ffacd0b85a97d-482b1e94d3emr3570625f8f.10.1787122402794; Tue, 18 Aug 2026 23:53:22 -0700 (PDT) Received: from localhost (109-81-87-166.rct.o2.cz. [109.81.87.166]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-482b14b802dsm3173435f8f.17.2026.08.18.23.53.22 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 18 Aug 2026 23:53:22 -0700 (PDT) Date: Wed, 19 Aug 2026 08:53:21 +0200 From: Michal Hocko To: Leon Hwang Cc: linux-mm@kvack.org, Andrew Morton , David Hildenbrand , Lorenzo Stoakes , "Liam R . Howlett" , Vlastimil Babka , Mike Rapoport , Suren Baghdasaryan , linux-kernel@vger.kernel.org, Lance Yang Subject: Re: [PATCH] mm: add cond_resched() to free_pud_range() Message-ID: References: <20260818134934.92354-1-leon.hwang@linux.dev> <2282ba9a-0c6a-4ce3-99ee-517231f515b6@linux.dev> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2282ba9a-0c6a-4ce3-99ee-517231f515b6@linux.dev> On Wed 19-08-26 09:51:00, Leon Hwang wrote: > On 18/8/26 22:08, Michal Hocko wrote: > > On Tue 18-08-26 21:49:34, 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. > > > > PREEMPT_NONE is effectivelly dead and most cond_resched will/should be > > removed. Is there any reason why you are not using full preemption when > > requiring low latencies? > > Seems that we have reached a consensus about adding cond_resched() [1]. I disagree. It makes zero sense to add more cond_resched calls unless they are essentially necessary. In this case you are talking about latency requirements while using non-preemptible kernel which is in stark contradiction. So either you have other very good reasons or just base on the current changelog Nacked-by: Michal Hocko > > [1] > https://lore.kernel.org/linux-mm/20260818162430.0a51522ac9bd671cce62650f@linux-foundation.org/ > > Thanks, > Leon > > > > >> 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); > >> > >> start &= P4D_MASK; > >> if (start < floor) > >> -- > >> 2.55.0 > > -- Michal Hocko SUSE Labs