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 3651732C309 for ; Tue, 16 Dec 2025 15:12:51 +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=1765897972; cv=none; b=qj70jomnIBP5SxPUj4QJdPlKvB6wEObKmFH0LfpIYSPkU16gserWYO7T7n5bNrlYaodqZqUimAxiiasMq4OEQxG+RZsLjrJAdDj1sMVIpNVeRTyZhsMVJ6KGB+u+hdkbJEGRySv6pC1DsnpxTezQtioRJY9N0selnrQx4l2/gRI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1765897972; c=relaxed/simple; bh=s3mWl19IsBaYscnhUDI/X0Sg6nqiJrXm+KLBkFlAHc0=; h=Date:From:To:Cc:Subject:Message-Id:In-Reply-To:References: Mime-Version:Content-Type; b=OQ6xC/5v2DCgPdFOd1Yj0fbX3WpFly/HhntqfeitCKaZ6X/oO3OyU8q31xdGw5QrsA13/iE6Am0QjT1wOKq5YE8DFvJuPKxMx+FyrLnT7QyRonTUq58ut9UYBma++Wh3U+Woghf/5L3OAOucRWCkrN1MXTK0lL2EmsgcEpTvcpg= 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=WtoEDxoF; 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="WtoEDxoF" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 2DB20C4CEF1; Tue, 16 Dec 2025 15:12:51 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org; s=korg; t=1765897971; bh=s3mWl19IsBaYscnhUDI/X0Sg6nqiJrXm+KLBkFlAHc0=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=WtoEDxoFxKkX6YD2btUH4i1VWm6UhQJlEN4mW18ItLNDGupYZX389yjw2v5Emgi0c fJBFQCUpLRXT1tdrt0HgN/fMMB98nltOA4QKQEo2QgZxINHj4cTzjYMWxP3W37cmqo GTIBOMhxxbGO/8Mw7bV1lyqFGRHJl44htjCtNv/g= Date: Tue, 16 Dec 2025 07:12:50 -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: <20251216071250.e49ecf7490acf7f377dbfdc0@linux-foundation.org> In-Reply-To: <874ipqexai.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> 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 Mon, 15 Dec 2025 22:49:25 -0800 Ankur Arora wrote: > >> [#] Notice that we perform much better with preempt=full|lazy. As > >> mentioned above, preemptible models not needing explicit invocations > >> of cond_resched() allow clearing of the full extent (1GB) as a > >> single unit. > >> In comparison the maximum extent used for preempt=none|voluntary is > >> PROCESS_PAGES_NON_PREEMPT_BATCH (8MB). > >> > >> The larger extent allows the processor to elide cacheline > >> allocation (on Milan the threshold is LLC-size=32MB.) > > > > It is this? > > Yeah I think so. For size >= 32MB, the microcoder can really just elide > cacheline allocation, and with the foreknowledge of the extent can perhaps > optimize on cache coherence traffic (this last one is my speculation). > > On cacheline allocation elision, compare the L1-dcache-load in the two versions > below: > > pg-sz=1GB: > - 9,250,034,512 cycles # 2.418 GHz ( +- 0.43% ) (46.16%) > - 544,878,976 instructions # 0.06 insn per cycle > - 2,331,332,516 L1-dcache-loads # 609.471 M/sec ( +- 0.03% ) (46.16%) > - 1,075,122,960 L1-dcache-load-misses # 46.12% of all L1-dcache accesses ( +- 0.01% ) (46.15%) > > + 3,688,681,006 cycles # 2.420 GHz ( +- 3.48% ) (46.01%) > + 10,979,121 instructions # 0.00 insn per cycle > + 31,829,258 L1-dcache-loads # 20.881 M/sec ( +- 4.92% ) (46.34%) > + 13,677,295 L1-dcache-load-misses # 42.97% of all L1-dcache accesses ( +- 6.15% ) (46.32%) > That says L1 d-cache loads went from 600 million/sec down to 20 million/sec when using 32MB chunks? Do you know what happens to preemption latency if you increase that chunk size from 8MB to 32MB? 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.