From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 097C7C3601E for ; Mon, 14 Apr 2025 07:05:34 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 33C9B280047; Mon, 14 Apr 2025 03:05:33 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 2EB31280046; Mon, 14 Apr 2025 03:05:33 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1B2FA280047; Mon, 14 Apr 2025 03:05:33 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id F10D0280046 for ; Mon, 14 Apr 2025 03:05:32 -0400 (EDT) Received: from smtpin06.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 9434A5BEAE for ; Mon, 14 Apr 2025 07:05:33 +0000 (UTC) X-FDA: 83331763746.06.B4646BA Received: from sea.source.kernel.org (sea.source.kernel.org [172.234.252.31]) by imf14.hostedemail.com (Postfix) with ESMTP id BAA21100008 for ; Mon, 14 Apr 2025 07:05:31 +0000 (UTC) Authentication-Results: imf14.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=vIt0GfAQ; dmarc=pass (policy=quarantine) header.from=kernel.org; spf=pass (imf14.hostedemail.com: domain of mingo@kernel.org designates 172.234.252.31 as permitted sender) smtp.mailfrom=mingo@kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1744614332; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=9E+8CHWnG3ZYfKMNTY06hUyl7JtBLL3dJnzFSlWoc1E=; b=RW2B9DwHlIPEjvkrGvB30l15dpctRuKAKvsfVR4OcvebRVXsaQdV9y1DYJQANd3dEcbLlP J0DH9DXbwm+VrvIEf/anVdcSkTmqEa7NwZpkPOwzGH+SdJ5XxHRi0AxDiaSK42T4hLxZIa m5S/Gb1/UfpnTwIZ2f2yJOxu2Wrlgfc= ARC-Authentication-Results: i=1; imf14.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=vIt0GfAQ; dmarc=pass (policy=quarantine) header.from=kernel.org; spf=pass (imf14.hostedemail.com: domain of mingo@kernel.org designates 172.234.252.31 as permitted sender) smtp.mailfrom=mingo@kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1744614332; a=rsa-sha256; cv=none; b=5ODIKz7C/S4efVdWt6CYSti+Jt8rbdeo1W9wRKbKZsXwTPd7BetKqzWKNESOvctnMwi7Dg xSTpN5GvysalSgAxitmvS2yBQk0M27+r8idUut+MGqLXR+5ixFc6LytuIYx3VIGO+dtC8A oo/KquyGCTwXwuuOvVNbTy/AiF9mFDs= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sea.source.kernel.org (Postfix) with ESMTP id 765AC4A422; Mon, 14 Apr 2025 07:05:29 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 89797C4CEE2; Mon, 14 Apr 2025 07:05:25 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1744614330; bh=44eQA72v4mswU9H8pQxV3pwz7lIjEJsLNjNcRvjEOQ0=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=vIt0GfAQxhuiTXukocJTAwdUin0sX3W/UfcDtA0luQx9PwscTsGLVyYrGdMS8qVJe AiJmcVvO6z41gI7516TEeJfxN7hvh4mqotBYfJWGLN057xJ2gEKSmzrZtNV0VbpGFe j1hvWWcAUfn1uzCgsUQ5Er2ZAvaVVZkzJTkuYl/WXwBOyyEv8OEKYhjPixJFljusoc k04dG1vhd8pck7ejeCgRCU5NA3hadf0gG1fnlevv310ANbVK4q3tkJfO8LPx5M7HUr 1Jv/8hsk6gF3H1M7MPrGrhpDiQ+KPqa90Jna3mzw8PPeLdJE1T6rVYTPmFMB9CmnXQ 0ZSH6wlIol60A== Date: Mon, 14 Apr 2025 09:05:22 +0200 From: Ingo Molnar To: Ankur Arora Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org, x86@kernel.org, torvalds@linux-foundation.org, akpm@linux-foundation.org, bp@alien8.de, dave.hansen@linux.intel.com, hpa@zytor.com, mingo@redhat.com, luto@kernel.org, peterz@infradead.org, paulmck@kernel.org, rostedt@goodmis.org, tglx@linutronix.de, willy@infradead.org, jon.grimm@amd.com, bharata@amd.com, raghavendra.kt@amd.com, boris.ostrovsky@oracle.com, konrad.wilk@oracle.com Subject: Re: [PATCH v3 4/4] x86/folio_zero_user: multi-page clearing Message-ID: References: <20250414034607.762653-1-ankur.a.arora@oracle.com> <20250414034607.762653-5-ankur.a.arora@oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20250414034607.762653-5-ankur.a.arora@oracle.com> X-Rspamd-Server: rspam11 X-Rspamd-Queue-Id: BAA21100008 X-Stat-Signature: b6mttoe83o4f9q63way4yu3qgnypeuhb X-Rspam-User: X-HE-Tag: 1744614331-272023 X-HE-Meta: U2FsdGVkX18Q2NbMr+3MxS+ehuyr+RGMKi5YyzxTLks6dkic7sr8JU0c7ffRXkjqhZxqvlNaUW1j5olo5613zAwjifl7xJUPg57o22e1OHWZsTP4z6TpcVueyNChBUrkFTfkDlK1dZ30SAV4A13rfYhp7tiMmlLED0u3hn1Q4F11MVtz59ZY3aDV8Zclp/Fcw9oxCaYYHUfDuv1Ayvb7a3P6eGKCLveJC1vvaNg8Ez5wde7af6uH6GtB/3lab7uaO7/5QrAeVoiMMJ+wtCxgQ1j6wFTdIN628QdKv6gPn+5hlqLD9sX25REJTx3j6iMEiQkVSIBFp8oJtjTzSyMYEJeoFj1pb7VKngFpI6D+SBjpL585D30TcGPvQ3FUwoMUCyjT6jE6mMxaJQnSdeGjrSDiEDmtJlp6Q9J4i7tpNbZfRZnrzpE+HNNG4RYefWqiKu63s+2H3Wr/czowmlfwGa+DcKeu3DBk2Rtt0EkuPYT2lbs5KJjXaUFVEktYHrCteeVBbeJ10RHT+lcnKIIQOhuXdx53SU3vWpUvo+BfcwBmKd281gNzzy1a7GAsUpL9lCn5BQA0h0ESkCCA3HKhL/N9YY88XA160eIWiho2MXFFlcAe4YcAc/E1fvw+E19x6uL6Xed3dDU9uXRuGLfLL8hMCdcJl5RdHCP4YYx9FUM+If/JoZYfeB9Ws0Es5QkhEhA1SPOzAc+jDU20oOFEn4povjhfoIn+a6BruJ0xHS98YJ2iRDyY0aKBsdug2A0DhxCOS9gWwLz/BYtWbuXPuTngtv1UJ0dUTespbXE3oDgtPY8brB9WS5W1WS44arSzSMq8rsS4exDjrG0ANiK1ILj1V02hh7gse8kRIJoQpfa6knKqDemWc5P/BammVJS6ZXl6NH5A4YMQUCEQo2eH7zaYHkLIB5xIatSAAeU3t3IC2jRa+Xg8/PUgqr8lH635pZ7zk3VJw7A7pZyTVMs Te1hKEK2 W1dwVp4kbGXIt9xUOvBN8n79vnrM36o+3u6pC7adCWNOudD3NnvDoyWDoxlQSWih9uiSb7t4GO9BqEGo89cstZjLn/ac0fu5YC7a7Gt2tTwOrhrlHSivYfnA/xWAfH5VJQvEkjsBKQT1cXITNhtqIvE0h+6z9disZnhol7XjD2uBgINoQ5wg7BKSdZmd/leWq3vbFBlxvCA3r2pjnC8aFxTWGltzUKd/06H3DY9RydMkNCjm0HaEZbhOMteb47zO01F6dsax6Q8O+oLBHSVDxCQNzj8QW3dWvRj+T X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: * Ankur Arora wrote: > clear_pages_rep(), clear_pages_erms() use string instructions to zero > memory. When operating on more than a single page, we can use these > more effectively by explicitly advertising the region-size to the > processor, which can use that as a hint to optimize the clearing > (ex. by eliding cacheline allocation.) > > As a secondary benefit, string instructions are typically microcoded, > and working with larger regions helps amortize the cost of the decode. Not just the decoding, but also iterations around page-sized chunks are not cheap these days: there's various compiler generated mitigations and other overhead that applies on a typical kernel, and using larger sizes amortizes that per-page-iteration setup cost. > When zeroing the 2MB page, maximize spatial locality by clearing in > three sections: the faulting page and its immediate neighbourhood, the > left and the right regions, with the local neighbourhood cleared last. s/zeroing the 2MB page /zeroing a 2MB page > It's not entirely clear why the performance for pg-sz=2MB improves. > We decode fewer instructions and the hardware prefetcher can do a > better job, but the perf stats for both of those aren't convincing > enough to the extent of ~30%. s/why the performance /why performance > For both page-sizes, Icelakex, behaves similarly to Milan pg-sz=2MB: we > see a drop in cycles but there's no drop in cacheline allocation. s/Icelakex, behaves similarly /Icelakex behaves similarly > Performance for preempt=none|voluntary remains unchanged. CONFIG_PREEMPT_VOLUNTARY=y is the default on a number of major distributions, such as Ubuntu, and a lot of enterprise distro kernels - and this patch does nothing for them, for no good reason. So could you please provide a sensible size granularity cutoff of 16MB or so on non-preemptible kernels, instead of this weird build-time all-or-nothing binary cutoff based on preemption modes? On preempt=full/lazy the granularity limit would be infinite. I.e the only code dependent on the preemption mode should be the size cutoff/limit. On full/lazy preemption the code would, ideally, compile to something close to your current code. > +obj-$(CONFIG_PREEMPTION) += memory.o > +#ifndef CONFIG_HIGHMEM > +/* > + * folio_zero_user_preemptible(): multi-page clearing variant of folio_zero_user(). We don't care much about HIGHMEM these days I suppose, but this dependency still feels wrong. Is this a stealth dependency on x86-64, trying to avoid a new arch Kconfig for this new API, right? ;-) Thanks, Ingo