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 EC690C369A2 for ; Mon, 14 Apr 2025 06:32:41 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 9A87B28003E; Mon, 14 Apr 2025 02:32:39 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 8B5B8280030; Mon, 14 Apr 2025 02:32:39 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 75A4528003E; Mon, 14 Apr 2025 02:32:39 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 4D30C280030 for ; Mon, 14 Apr 2025 02:32:39 -0400 (EDT) Received: from smtpin21.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 92363161858 for ; Mon, 14 Apr 2025 06:32:40 +0000 (UTC) X-FDA: 83331680880.21.3C071BD Received: from sea.source.kernel.org (sea.source.kernel.org [172.234.252.31]) by imf01.hostedemail.com (Postfix) with ESMTP id C924B40008 for ; Mon, 14 Apr 2025 06:32:38 +0000 (UTC) Authentication-Results: imf01.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=ktR1h8Ju; spf=pass (imf01.hostedemail.com: domain of mingo@kernel.org designates 172.234.252.31 as permitted sender) smtp.mailfrom=mingo@kernel.org; dmarc=pass (policy=quarantine) header.from=kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1744612359; 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=jqsa09HbBEzmyo+qpmkKEWnDSA7nMnd483ziEHtOsCU=; b=nUL3hnVEewPuTml4h5JZB+/JP3jXC1vOusv7YuTuSBAciW5iUahgDrFXppLrRXo9rkKuf9 PZsrJGNJy6GFE4Mk9+sQI8U/GfniZ8HOohHvl0PjG3yx2k+JTavDtnsgxpVjOLgEjATuli 6Dp2f7gQxG3P27wCNMpQu5hJyfRFRbU= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1744612359; a=rsa-sha256; cv=none; b=ODibGq8ixsAOYzK11nKIaCNMZRE0VpAm8znbmVa6KqlLAb3Zjn6ltMCWgerjGzPrwD1MMI zdEsofHd3r8xZGCEc9LrzmneK2491SUNd4yc7RrK//Jd1KpFzG2bPNLafuEn24wPGJcXqp SvVlJhEFsWNznMCUOc8N4XZurlDzMkE= ARC-Authentication-Results: i=1; imf01.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=ktR1h8Ju; spf=pass (imf01.hostedemail.com: domain of mingo@kernel.org designates 172.234.252.31 as permitted sender) smtp.mailfrom=mingo@kernel.org; dmarc=pass (policy=quarantine) header.from=kernel.org Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sea.source.kernel.org (Postfix) with ESMTP id 755FC44DEB; Mon, 14 Apr 2025 06:32:36 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id B6CA8C4CEE2; Mon, 14 Apr 2025 06:32:32 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1744612357; bh=EsnzLqlAA53UvsolhqObhC929/tsG0a5GbdMQu0r4vM=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=ktR1h8Jul5fv6V5VgCcaDbnGMQD3A4vvm97Cgd45ocrhZXIeMXMuyRV985aglOziD OPXYJDddj9JmuPYWdclGblAouOjwToz8LFwKC4pOf3DFmmSkTfXzp6Dq2IcBTT6f0C HbAp+0aKeWM+5QwWIr395EENiedS956r9FO3fvGJGFMSLu2QwuxNIDvjeRZI22udYs dpOXShyqvoObbmA5Yyt/h7VZJeUvMSyZuYC+ZNxajGX4AlgO8R3fcumafjj2wspdmQ y0LQKUL7EMpqfrSExErORJhobIylJcURmgYp9InrGRZseucQG17XKZXQ7cbSrI5+jv XvNhrvWIVaI4Q== Date: Mon, 14 Apr 2025 08:32:29 +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 1/4] x86/clear_page: extend clear_page*() for multi-page clearing Message-ID: References: <20250414034607.762653-1-ankur.a.arora@oracle.com> <20250414034607.762653-2-ankur.a.arora@oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20250414034607.762653-2-ankur.a.arora@oracle.com> X-Stat-Signature: bhrg1m6cnbjth83uu3ec6fa17nqc6yw7 X-Rspam-User: X-Rspamd-Queue-Id: C924B40008 X-Rspamd-Server: rspam08 X-HE-Tag: 1744612358-350009 X-HE-Meta: U2FsdGVkX19AsIAJlMDN+UmBk7qGYVGQnRqCQSpgPimdicYt5/T/jJ854/yIVs2VmTTmKh8a2K9i4472k5kPmvr/7MKISbYlEP0xjCdS9Uw/PX1yWeHYXViP1+54X6uUEj+0vzuC9B3uF3jV69m1dqSs77D7fhJPEbXnbfDV2/VSwfHsmX5zvHgUpVZKIUCXtMqK4InRzbm1NSmad+2LeDPYbv6CYeiOnUYVdZDz5V+VCoiAjz4JRVLWIi3VGqGggONwn1zlJSd+NF9Qr15i32/A/8Tbmeyq8toc5Ve9BXqadUdnEstTKb2cD892avRdxaB1Iwyvq5BANXrrGmu4fQsVm0hW/BsB1Vw4o9n5q9fOEohg7Vdi9al0afyJaAYXS3JRkJZ1XRVdNdO2aEk4lXy3URZ6tJee3PfoGfX4jK4Mkhdc/RzqFioVgxQz48XnOy79JIoC6++sxQm3Gx4WGhmMXnR8f/mrTGshgjFni9m5JIvYP77MU7X9owPlWhq1daM4MaQ6JCc4tytdpW4OwLV2bvyfmqBUWqwcIiaSFLZKCqgeBETfi2omeM2HVsjy3S8Vb9jlFq//D+gCDKBInJHbRfVnEyPYBeyUV0GXhhDZlfT50656gd93OPZgSEN/oGhvxgBodBzt+RH6XWyRX4QnzA9pVInOKJlzlzL7b1Y6ZudeHYbzi+90MF92GVAVJv9wo2dNPRn7wMpBtcu6Mk2a6TpsXZxAE24LHG0l0I8UZDY+k+tgjmjrA5GMurRzNi7VV84IMSMHCwCxOrLQgNkdRqfai8FzL1MXzsjepuGmSgVD2sThYGfRj1dm1wB3xQfm39dxkazQ7RLOkKD3DRImnrlvzzad98gv8gM68cCXxeccN8x2B5Xldw8umuNitSrdVPsH8mTsIExQKsIfoBmCWlCEeC1pyAlmIEjquLGIYXW2T9rBdD/k/HDVnYzjIBZQY3z4NFQ3meZYT8E t80PVAkW 3KjFvG8Q6M5kOgKNNIvMb6cscb/Uk7ocBN3Wyk/Nk4tVNrXsgFnvQbBge37hTqhFHVTm37J2jDlvipW6xYwVCfxcXnxAbW/0H70YTCDUM36UKp7CTNQ3HW+rIQRfexo35m1eNtReI11LPpN9EpGzfYKuB0uQ4d/qlMulVFynhR0hYyz1vqx5Y6sPcRvVdIzuPTl5m/2OclymqhnI9wG9fhCY2KZV3ssw/LDaqmSar3N+51MUWym0Bas5bYMllbLhX9Muk471i4U/Wz2rZO65jhwK12GDf3VSCEJEc 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_page*() variants now take a page-aligned length parameter and > clears the whole region. Please read your changelogs and fix typos. ;-) > +void clear_pages_orig(void *page, unsigned int length); > +void clear_pages_rep(void *page, unsigned int length); > +void clear_pages_erms(void *page, unsigned int length); What unit is 'length' in? If it's bytes, why is this interface artificially limiting itself to ~4GB? On x86-64 there's very little (if any) performance difference between a 32-bit and a 64-bit length iterations. Even if we end up only exposing a 32-bit length API to the generic MM layer, there's no reason to limit the x86-64 assembly code in such a fashion. > static inline void clear_page(void *page) > { > + unsigned int length = PAGE_SIZE; > /* > - * Clean up KMSAN metadata for the page being cleared. The assembly call > + * Clean up KMSAN metadata for the pages being cleared. The assembly call > * below clobbers @page, so we perform unpoisoning before it. > */ > - kmsan_unpoison_memory(page, PAGE_SIZE); > - alternative_call_2(clear_page_orig, > - clear_page_rep, X86_FEATURE_REP_GOOD, > - clear_page_erms, X86_FEATURE_ERMS, > + kmsan_unpoison_memory(page, length); > + > + alternative_call_2(clear_pages_orig, > + clear_pages_rep, X86_FEATURE_REP_GOOD, > + clear_pages_erms, X86_FEATURE_ERMS, > "=D" (page), > - "D" (page), > + ASM_INPUT("D" (page), "S" (length)), > "cc", "memory", "rax", "rcx"); > } > > diff --git a/arch/x86/lib/clear_page_64.S b/arch/x86/lib/clear_page_64.S > index a508e4a8c66a..bce516263b69 100644 > --- a/arch/x86/lib/clear_page_64.S > +++ b/arch/x86/lib/clear_page_64.S > @@ -13,20 +13,35 @@ > */ > > /* > - * Zero a page. > - * %rdi - page > + * Zero kernel page aligned region. > + * > + * Input: > + * %rdi - destination > + * %esi - length > + * > + * Clobbers: %rax, %rcx > */ > -SYM_TYPED_FUNC_START(clear_page_rep) > - movl $4096/8,%ecx > +SYM_TYPED_FUNC_START(clear_pages_rep) > + movl %esi, %ecx > xorl %eax,%eax > + shrl $3,%ecx > rep stosq > RET > -SYM_FUNC_END(clear_page_rep) > -EXPORT_SYMBOL_GPL(clear_page_rep) > +SYM_FUNC_END(clear_pages_rep) > +EXPORT_SYMBOL_GPL(clear_pages_rep) > > -SYM_TYPED_FUNC_START(clear_page_orig) > +/* > + * Original page zeroing loop. > + * Input: > + * %rdi - destination > + * %esi - length > + * > + * Clobbers: %rax, %rcx, %rflags > + */ > +SYM_TYPED_FUNC_START(clear_pages_orig) > + movl %esi, %ecx > xorl %eax,%eax > - movl $4096/64,%ecx > + shrl $6,%ecx So if the natural input parameter is RCX, why is this function using RSI as the input 'length' parameter? Causes unnecessary register shuffling. > +/* > + * Zero kernel page aligned region. > + * > + * Input: > + * %rdi - destination > + * %esi - length > + * > + * Clobbers: %rax, %rcx > + */ > +SYM_TYPED_FUNC_START(clear_pages_erms) > + movl %esi, %ecx > xorl %eax,%eax > rep stosb > RET Same observation: unnecessary register shuffling. Also, please rename this (now-) terribly named interface: > +void clear_pages_orig(void *page, unsigned int length); > +void clear_pages_rep(void *page, unsigned int length); > +void clear_pages_erms(void *page, unsigned int length); Because the 'pages' is now a bit misleading, and why is the starting address called a 'page'? So a more sensible namespace would be to follow memset nomenclature: void memzero_page_aligned_*(void *addr, unsigned long len); ... and note the intentional abbreviation to 'len'. Also, since most of these changes are to x86 architecture code, this is a new interface only used by x86, and the MM glue is minimal, I'd like to merge this series via the x86 tree, if the glue gets acks from MM folks. Thanks, Ingo