From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f51.google.com (mail-wm1-f51.google.com [209.85.128.51]) (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 229233C3F75 for ; Wed, 19 Aug 2026 08:59:19 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.51 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787129960; cv=none; b=VsGVok0kN9F6R9bUkatclSt+P2z0eAt5EtBztkLO9o4dnRvQ9iTXymP3zQsP4hDQX5Z6KkqEY7q/zl0Zl9WsT8OrOVHz5iomA7Hx+Oipznur1l9wcdFac9DxvD2loJch6XnXlwEKuFJd1ouvyK0oawEvHV6ZUe7Clpfiluttv48= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787129960; c=relaxed/simple; bh=DtIqjSAcaOVUBZSR1Lgx9YPhTT0eWx9PwCgpYK2JePk=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=k+Jdll/qE6F+Hw8qDkU7rCJGNmpwx+weYB4R1nEr2olsZbHrlKfDNwKHauy83PVBROs9OQCpGqxO8Drgzvhn0iv6Ae9k4R/dQAg/Os8TpOzrUadFub6Utyb9nAUA52Rvxa7WBDbg/7zmRoJZ4UjE3nrevrzNqLiz3fxbDsrEZQw= 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=Z1mgoLHG; arc=none smtp.client-ip=209.85.128.51 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="Z1mgoLHG" Received: by mail-wm1-f51.google.com with SMTP id 5b1f17b1804b1-490cf322ed0so6778755e9.1 for ; Wed, 19 Aug 2026 01:59:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1787129957; x=1787734757; 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=nPBuvlSTVq/cy1aSyLelT0W4GC3jLLC5QYRU+QpaQtU=; b=Z1mgoLHGX0VwjcxyHZTESK3fDDewC8+ej3e6GSlxVscgsH+PiBJuAPJ+abiDxnAQog zzHPytd+P+c3qg2wnBSDK5rZoLeExDBZOMDe4Wcq7upAw3FQWGQLv747ziowDaszxCcu mBVn+WN3PB5gIuOoi7gK3AoKFbCtS8fdpMwu/LnUBiiHY9UbCuKnWPwt87bgB3gzabes zTiwaO3Lql4gro+Ig/M57s69Dxj6soOUpYDZrvCe9jNIYHt5aGBNnVfxmDjrKG1NgJMx OIlnYlfIxlV7HuykytsuvZPHxFL/bhU/c5Z10+vf1jYv3I9yoKHAQU0GHu3EWTCUspgZ LiDg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1787129957; x=1787734757; 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=nPBuvlSTVq/cy1aSyLelT0W4GC3jLLC5QYRU+QpaQtU=; b=QseogUcp4bM7+o2N3AouWwUzjI9bSIRfJi6E1wd5eRkNXUUlvyIyhUZpInKcupVlmy clM+sCijasrWi4SK815/j+XrQSJCyZO0ElNjqqGbgiaS/HCQT26FLMNGV+TuwZQSvoJd j0SYDnksGGoEWqsUkq1S2lbR/B+pmMcP/4/jwshnX2Mj2njT6rfIQYf/CNJfmqiOcuzx q3QRdFEBg772DZS9oQNbAdE1Py8a9aFsrpvUrSBKjbc6xWNtm3KKXP7meSuAGYaIzW2T Xo+3mBoHiOo6Hu0UNIsRhT9qwl7l3bROW0lFZP+uEzUyanYBpFGuuwbPWGJSFEdDOXtp ZR6A== X-Forwarded-Encrypted: i=1; AHgh+RrJjekhCmXpngmPec2JUFdkMqe5LY7cM5b9FfYr24z/BTAMNIxb2nhpnrxh+4hLtAnuAUAXKpE0HXtbocA=@vger.kernel.org X-Gm-Message-State: AOJu0YytzTpC5xPHXKhYB/jc5+AozME0QJKuOh5fcLTZWq7NnrijhapB lftFnS4RoYp5sgesSGek2EiRE/CCNeZ8fxjaP48vuYvAaypQSo3CrLvlY89Z3ovBJ6g= X-Gm-Gg: AR+sD13uPbcU6j9gUyVpdm2seOy3v34almUWfwUkcAwuxjT29rdkqDPUWMUpFW05qIw PWWFK1FoG5UMtUEP82umHnfttd/5g31jtHFxMo+e6nZ4/Nd+9s1+H30im//Z9P/7Q6VncVrbp2M S9T0otJSm3R2IwzdFe5zr+ZsZ+MgMfuuSf70GMBlWwzpn/SNKF6Sq9UsOn443932dXZq3fzYWFC tPf9L5cPLVlgNqVueZkT4aPNsVfa5PVqucNXYQB8ez1g5uoQ+4bn3P4wk8ARcO+8Zx/eyjA9KKn TtCOkbb2F49riANA3bItE8l4J03KHZ2rUNCqe4B0x8vy2KYomKlTZjsdRtfJ0/hWS6Xa4WVkqGs wKEXRS8olfuz7WCu0V59EUBcCUh5mZLd93VcGyMnd3CBNg4qpmOSJLAu4FMNiiCC+9m/Suw5AjX qeTLWW3RS9JDeNViBhAdUxPfPLjjxwonpUbrXbulBAA/ETg+o7OXDZQr+PH3Q6O7Ud9xNHTNkgV A== X-Received: by 2002:a05:600c:37c6:b0:499:87f3:a2a3 with SMTP id 5b1f17b1804b1-499aa1c7bafmr55530255e9.15.1787129957417; Wed, 19 Aug 2026 01:59:17 -0700 (PDT) Received: from localhost (109-81-87-166.rct.o2.cz. [109.81.87.166]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-499aa1755b2sm45456595e9.11.2026.08.19.01.59.16 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 19 Aug 2026 01:59:17 -0700 (PDT) Date: Wed, 19 Aug 2026 10:59:15 +0200 From: Michal Hocko To: "David Hildenbrand (Arm)" Cc: Andrew Morton , Leon Hwang , linux-mm@kvack.org, Muchun Song , Oscar Salvador , linux-kernel@vger.kernel.org, Lance Yang Subject: Re: [PATCH] hugetlb: add cond_resched() to __unmap_hugepage_range() Message-ID: References: <20260818135029.93288-1-leon.hwang@linux.dev> <3dadebb3-7e2a-459c-a5e8-b375faf89938@kernel.org> <20260818111756.6b0e347db3170bc22cc3c5af@linux-foundation.org> <2a523945-825c-45a5-a680-37e941e092d3@kernel.org> <20260818115526.654d7311366b66cd031c67e4@linux-foundation.org> <35cca76a-4d3a-451a-b492-dd4423ac3e63@kernel.org> <68cb43c6-6ed2-488f-916a-b22bb956adcf@kernel.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=us-ascii Content-Disposition: inline In-Reply-To: <68cb43c6-6ed2-488f-916a-b22bb956adcf@kernel.org> On Wed 19-08-26 10:54:11, David Hildenbrand wrote: > On 8/19/26 10:50, Michal Hocko wrote: > > On Wed 19-08-26 09:53:25, David Hildenbrand wrote: > >> On 8/18/26 20:55, Andrew Morton wrote: > >>> > >>> > >>> 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). > >> > >> It's tricky: if a problem only exists in stable (there is nothing to fix in > >> Linus' tree), then a stable-only fix is acceptable. > > > > The crucial quiestion is whether this is something that needs a code fix > > or a configuration fix. Really fighting for low latencies with > > PREEMPT_NONE is a kinda lost battle. You might want to play whack a > > mole... > > Yes, I read your comment on the other thread afterwards and I agree. > > The whole reason we added cond_resched() all over the place over the years was > to avoid splats from false detected hung tasks (e.g., 30s ...). > > Not to optimize latency in the ms range. Exactly, they aimed to provide reasonable upper boundary of no-preemption with non-preemptive scheduling. And those are on decline which is a reason to keep bar for adding new ones high and also optimizing low latencies fundamentally makes no sense for those models. So even more reason to not add them in these cases. This will just add more future work when non-preemptive models are gone which will eventually happen AFAIU. -- Michal Hocko SUSE Labs