From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mta1.migadu.com (out-39.mta1.migadu.com [95.215.58.39]) (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 D53ED263F44 for ; Tue, 18 Aug 2026 22:19:17 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=95.215.58.39 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787091560; cv=none; b=s5vzvi6cM7Oojrhx9LBmr62dGrtIna3WkdXyptiGfDppl4ugNzrPLcUAsHTpMsNLv00DR9gRiUoIG3QzM2GljVWX0cc4dXySRGdT/Y0juweVe36c0tAmeXI1WarvtmVbPdTs7gUF/OEwRcZNTZ1VNoiZ033mnqfTPCto+vAuFOE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787091560; c=relaxed/simple; bh=L+2aeKPcHyJYbAXWC/tMY7CVwT8jSrUG9YyRuMei8kI=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version:Content-Type; b=q9A49qm7D9dvMkUydtK5tz+cVhpPS3NRI1/EPs5a7aVMno6gvSo1/Rr/rJaz7oUhBVjhr1FQhwsN3+EfjBLWTbe1dyv3CQOqVVOjZEFfcpX/6Ay40lhq745UzsoR+KbmJ8ZdIwCxKodIZ/auYEDVbYB/WkIJng6gni9RF24nx/U= 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=ZcC2HYW1; arc=none smtp.client-ip=95.215.58.39 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="ZcC2HYW1" X-Envelope-To: linux-kernel@vger.kernel.org DKIM-Signature: a=rsa-sha256; bh=L+2aeKPcHyJYbAXWC/tMY7CVwT8jSrUG9YyRuMei8kI=; c=simple/simple; d=linux.dev; h=from:to:subject:date:message-id:mime-version:content-type; s=key1; t=1787091555; v=1; x=1787696355; b=ZcC2HYW1Q2r4Yt9tTGLc7EQ6daUehB9OD2wdntA4wLM5jOseAbRS0tHl4cW3908ZkzBFQQBF 0zEYd4X5ijKRXUBYdIizpv/8dp2ZvKR28x1HHAp/x8ZF36RLYHuW1hXXUOUA4li18LxQkawl1Gp 43mja065yZPX478kxZzuwTo8= X-Envelope-To: linux-kernel@vger.kernel.org Received: from localhost (2602:fce1:44f:115e::) by smtp.migadu.com with ESMTPS id 40f4e78686b61702; Tue, 18 Aug 2026 22:19:05 +0000 X-Migadu-Flow: FLOW_OUT From: Lance Yang To: david@kernel.org, mhocko@suse.com, akpm@linux-foundation.org Cc: leon.hwang@linux.dev, linux-mm@kvack.org, muchun.song@linux.dev, osalvador@suse.de, linux-kernel@vger.kernel.org, Lance Yang Subject: Re: [PATCH] hugetlb: add cond_resched() to __unmap_hugepage_range() Date: Wed, 19 Aug 2026 06:18:58 +0800 Message-Id: <20260818221858.86452-1-lance.yang@linux.dev> X-Mailer: git-send-email 2.39.3 (Apple Git-146) In-Reply-To: <20260818115526.654d7311366b66cd031c67e4@linux-foundation.org> References: <20260818115526.654d7311366b66cd031c67e4@linux-foundation.org> 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=UTF-8 Content-Transfer-Encoding: 8bit +Cc Michal On Tue, Aug 18, 2026 at 11:55:26AM -0700, Andrew Morton wrote: >On Tue, 18 Aug 2026 20:21:37 +0200 "David Hildenbrand (Arm)" wrote: > >> >>> if (!ptep) { >> >>> address |= last_addr_mask; >> >> >> >> As Michal just put it: >> >> >> >> "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?" >> >> >> >> https://lore.kernel.org/r/aoRnUxUlgf_kRlm8@tiehlicka Ah, I missed that PREEMPT_LAZY is now the default on major archs and PREEMPT_NONE is effectively gone there ... >> > >> > That's pretty bad behavior and we might want to fix it in earlier >> > kernels. Is PREEMPT_NONE effectively dead in 6.18.x and its >> > existing users? >> > >> > If yes, we do want to fix older kernels then we should merge this. >> > >> >> Okay, but that would be stable-only fixes? > >Not understanding. > >Maybe you refer to adding a patch to -stable but not to -linus? That's >against the -stable rules >(Documentation/process/stable-kernel-rules.rst). Since cond_resched() is a scheduling no-op under LAZY/FULL anyway (only the __might_resched() debug check remains), why not take this upstream with Cc: stable? Mainline scheduling stays unchanged, and stable can pick it up for old PREEMPT_NONE kernels. wdyt? Thanks, Lance