From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (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 951C917B425 for ; Wed, 17 Dec 2025 18:54:28 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1765997668; cv=none; b=jSzxIp/NswwZCZ+UrjKi5IGReq19AJF4oSyXxx8Lzjop5ZHuBYcMaqiOdIJhCfLWyDeLBHAnOSV8uPAxSiddJBvW47hoSL+DlA1sOv1VkT6oGrqTnme8dnx3Z7WgpS99RKVjYv467vkjp9m9u9dR77bksXlpBAVvET2oEoXRQ18= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1765997668; c=relaxed/simple; bh=UFy5VoMJgJWDegfLPFYjegCo6V9/j0kd50sEbbKUC1Q=; h=Date:From:To:Cc:Subject:Message-Id:In-Reply-To:References: Mime-Version:Content-Type; b=e8YTirSsldmQ9OXExfOfSp2z2OEL+BZv62YgBc9LRo2FnBm45hi3HFKSpGmFNZ82m63zbQDcswdq5M6xXsC+obTVCQFbOZNGQ/+93/avFxaFGZhUa0pxdddi/XXZsZScxDHyBxt3AxFf6D+fTwyFQ55fjyKGPYGNNvy4p8thuAI= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux-foundation.org header.i=@linux-foundation.org header.b=AyfLcPLr; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux-foundation.org header.i=@linux-foundation.org header.b="AyfLcPLr" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 800F9C4CEF5; Wed, 17 Dec 2025 18:54:27 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org; s=korg; t=1765997668; bh=UFy5VoMJgJWDegfLPFYjegCo6V9/j0kd50sEbbKUC1Q=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=AyfLcPLrRvfchnBfMKPYwdOOu1UiM4BKHqjiErohamcPpOdn65yzlIGyPrwF0e7px 83dSOl3MRI8wwykW/cJ0Vv/TA2kldAaYueeVhCq4+NpEAbNja3fMIJyUYR0ilM0GWk Pjxb8MsZdOLyEIaxn02C80FNsR72mymDBLdruRJs= Date: Wed, 17 Dec 2025 10:54:26 -0800 From: Andrew Morton To: Ankur Arora Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org, x86@kernel.org, david@kernel.org, bp@alien8.de, dave.hansen@linux.intel.com, hpa@zytor.com, mingo@redhat.com, mjguzik@gmail.com, luto@kernel.org, peterz@infradead.org, tglx@linutronix.de, willy@infradead.org, raghavendra.kt@amd.com, chleroy@kernel.org, ioworker0@gmail.com, boris.ostrovsky@oracle.com, konrad.wilk@oracle.com Subject: Re: [PATCH v10 7/8] mm, folio_zero_user: support clearing page ranges Message-Id: <20251217105426.5f03b5e8abd2e50faee9f49f@linux-foundation.org> In-Reply-To: <87fr994hot.fsf@oracle.com> References: <20251215204922.475324-1-ankur.a.arora@oracle.com> <20251215204922.475324-8-ankur.a.arora@oracle.com> <20251215184413.19589400a74c2aadb42a2eca@linux-foundation.org> <874ipqexai.fsf@oracle.com> <20251216071250.e49ecf7490acf7f377dbfdc0@linux-foundation.org> <87fr994hot.fsf@oracle.com> X-Mailer: Sylpheed 3.8.0beta1 (GTK+ 2.24.33; x86_64-pc-linux-gnu) 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-Transfer-Encoding: 7bit On Wed, 17 Dec 2025 00:48:50 -0800 Ankur Arora wrote: > > At 42GB/sec, 32MB will take less than a > > millisecond, yes? I'm not aware of us really having any latency > > targets in these preemption modes, but 1 millisecond sounds pretty > > good. > > Agreed. The only complaint threshold I see is 100ms (default value of > sysctl_resched_latency_warn_ms) which is pretty far from ~1ms. > > And having a threshold of 32MB might benefit other applications since > we won't be discarding their cachelines in favour of filling up the > cache with zeroes. > > I think the only problem cases might be slow uarchs and workloads where > the memory bus is saturated which might dilate the preemption latency. > > And, even if the operation takes say ~20ms, that should still leave us > with a reasonably large margin. > (And, any latency senstive users are probably not running with > preempt=none/voluntary.) So I think you're saying that yes, we should increase the chunk size? If so, what's the timing on that? It would be nice to do it in the current -rc cycle for testing reasons and so the changelogs can be updated to reflect the altered performance numbers.