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 261D9C3DA7F for ; Mon, 5 Aug 2024 19:38:44 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 6D74C6B007B; Mon, 5 Aug 2024 15:38:44 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 687846B0082; Mon, 5 Aug 2024 15:38:44 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 54EA96B0083; Mon, 5 Aug 2024 15:38:44 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 3351B6B007B for ; Mon, 5 Aug 2024 15:38:44 -0400 (EDT) Received: from smtpin27.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id B60D1C01FE for ; Mon, 5 Aug 2024 19:38:43 +0000 (UTC) X-FDA: 82419204126.27.276980C Received: from mail-ed1-f42.google.com (mail-ed1-f42.google.com [209.85.208.42]) by imf03.hostedemail.com (Postfix) with ESMTP id DA12620024 for ; Mon, 5 Aug 2024 19:38:40 +0000 (UTC) Authentication-Results: imf03.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=zmbTCoPW; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf03.hostedemail.com: domain of jeffxu@google.com designates 209.85.208.42 as permitted sender) smtp.mailfrom=jeffxu@google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1722886675; a=rsa-sha256; cv=none; b=G20dz1V0yetpuqf6ajQCVJ0nX+fASX0jXtLKhBd5mEoeoe9sqQwGz3C43x97vgpZTVDLlU HpqqsJMbf92eBR+aOMeYOQLVHoXiCo+3A9UumKJfudB8DjxEoBLXn9wvJUdpTKYy+/DTP7 OdB9Ylzbx39T4xnwlGm9i7aDMUXet+M= ARC-Authentication-Results: i=1; imf03.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=zmbTCoPW; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf03.hostedemail.com: domain of jeffxu@google.com designates 209.85.208.42 as permitted sender) smtp.mailfrom=jeffxu@google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1722886675; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=SGFLA8u5kVy9wXjCmZIlQqKbRlxt+hHLnh+5Z8PTNyQ=; b=iqU5l3R2/vw8r40OwzxsAXH5DA4aQ7LNkaxun9PGvOX65fqyBkkRx2FErAWFUdNlIbCRqz JWarENNUi0Uq78HfqMg88ZRxl6OeR5uik3NhjMvfupcd+HbKyWDlMy3sBvS9t3keiOFfjU sXjL2av6KGPnh4EPU4wWwNnfXt3S20I= Received: by mail-ed1-f42.google.com with SMTP id 4fb4d7f45d1cf-5a18a5dbb23so450a12.1 for ; Mon, 05 Aug 2024 12:38:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1722886719; x=1723491519; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=SGFLA8u5kVy9wXjCmZIlQqKbRlxt+hHLnh+5Z8PTNyQ=; b=zmbTCoPWAlpdr2E1JG/nUK3+kL26QDUGQDc6MHFMhlxiOt46K/qiu4DdM41Qd3zvgE kuTDLPd6Z6ctZWO/ZlUadK99rA3lzEBtq+yQJ0oSUdAmGB4kGUT2HEdfww6B+5rpHIQF DkJ9uXLPmR7yRvlGVlCvHEiKd0P2nm72ur+gOP8ODtSyvj1T3jz6WP4CTpnrO+kGggD0 XKtPzTZBY8NTDVv8nEKgZ5tXyPnLV4LaDrG5wnAvt/qj08tq/F4RgHvLl03UzSeHFUfR vqj2Ka9UL3ZJuBaBPZDQovF83QPJhFAVsm8vWNuxfq1p4XhlTJhoyFYFimeJGxUI3lcr 026g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1722886719; x=1723491519; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=SGFLA8u5kVy9wXjCmZIlQqKbRlxt+hHLnh+5Z8PTNyQ=; b=kY+vh5oEL74sWig2kn6vUxIsNrtTJyZmfZBeyjctKO4Gh8Wms6m0q7s9rlwroHLm+w eSiV/9n1RoO/9o4Q6eTUSISmbuFbxrkI/XA4KEVYcBcRnitaDPIPWjHJhGiz5h0uVrrz 7tQ5qkAOAEwLHeWdmc+2ZatWlXpY3TGV2MxWtUSyPUI9nGFvhOXiE1YO9G78RFVQvdyz PeLsC+lqlM3x8aI8Bsci9cYdnZZna8pC3LaW2VW5DVVaX6KmveTdIEd/FcdS2+LRhiYE 5fOPk2oLj0cWtHrq/NDPabnxs56jTsXhO/f8M0lAyfVfGLhkIRdy6AYdwvT257HOyIN0 OYhg== X-Forwarded-Encrypted: i=1; AJvYcCU9pIKjXKxsJe6FvL5eh4dcm/tLsT9liLjAqDE6pVhc3K1mn+qjDCW+HpYQ5scH0aYMcVNqedVleWm5yBAxJyj3RkM= X-Gm-Message-State: AOJu0Yz4OYmtQUkEDQjsCfpHJ1QeiFcR3153UDCIKD9yxvWPO8KlQbyZ 7/4nBaQow8HTW2JuEdk/dbHqos5lmli7TJwuDGBozmZY5HrU3GG7gfwWQeI55diilKjOr4++vdu j1rdHkzXdTpGgjJkan2eY1KpeUXIg2OysRPg8 X-Google-Smtp-Source: AGHT+IGmnVv7No8+G2Cs5AvUBwMA5qb7rdRi/0cz257O9aMxeMc8HSPoAnLiEuwYAJwbFjE867spVvmZ03q036DH4uc= X-Received: by 2002:a05:6402:40c5:b0:57d:436b:68d6 with SMTP id 4fb4d7f45d1cf-5bb98397eecmr19552a12.7.1722886718833; Mon, 05 Aug 2024 12:38:38 -0700 (PDT) MIME-Version: 1.0 References: <202408041602.caa0372-oliver.sang@intel.com> In-Reply-To: From: Jeff Xu Date: Mon, 5 Aug 2024 12:37:59 -0700 Message-ID: Subject: Re: [linus:master] [mseal] 8be7258aad: stress-ng.pagemove.page_remaps_per_sec -4.4% regression To: Linus Torvalds Cc: Michael Ellerman , Nicholas Piggin , Christophe Leroy , Pedro Falcato , kernel test robot , Jeff Xu , oe-lkp@lists.linux.dev, lkp@intel.com, linux-kernel@vger.kernel.org, Andrew Morton , Kees Cook , "Liam R. Howlett" , Dave Hansen , Greg Kroah-Hartman , Guenter Roeck , Jann Horn , Jonathan Corbet , Jorge Lucangeli Obes , Matthew Wilcox , Muhammad Usama Anjum , =?UTF-8?Q?Stephen_R=C3=B6ttger?= , Suren Baghdasaryan , Amer Al Shanawany , Javier Carrasco , Shuah Khan , linux-api@vger.kernel.org, linux-mm@kvack.org, ying.huang@intel.com, feng.tang@intel.com, fengwei.yin@intel.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: DA12620024 X-Rspam-User: X-Rspamd-Server: rspam05 X-Stat-Signature: mmdf5mt5ssak3q4b66mng4to1hpxj5ed X-HE-Tag: 1722886720-328338 X-HE-Meta: U2FsdGVkX1/HhloUxHoKf2NmpSsJ0vLJp5v797ilE8R3KG1qzm7DTsZ96kbUf1o9eX1tAD5wXxR4fAH1oiW8B7Qq5F2+2fPE43/KrJIUdB7vQO1mCfozKbUXx/jEkOTRAEr+NreR/IAFswF+pVaVSCgcsF8dGHMjQTGHIQlcR6U69c8Usn3m5B1JWo2+YjCv4FlANEQbs0myv5t6fDO0lH0nNjpQqoo+9GXHtjGdnGARF17qK4O8Wxws1/PxFmsj2UJxZlIbKx4yk1JDCCnhvqlQEGEu7118Cc22Lil+4s64fkdBMkH9K1XT8EWe84ICRoBsN92Pt729qLvtvb0ZkBZdUTFXdNTZTS0WZkp/t6WszcjRVLy+go2s+LJZNEPI4jRPETOdvG9A0oKSra2X4DB2W3R4pI4tdgQPZVOJjFs6wNI/qq31Zyzwj+T+bsXtapgIMDMXuLVXTb05e+v+ZHITbey8wNqlppbPRdIaaqPxA6T4lP6FDWTPMxd944xg+DMY2YPJL0eEBxHGj9Zuwu9XceG6rio1ZLASWyt/E01ch5acNIQgIfCYNMx4Lba1oSoVGBm2J8x55ma5zZvIbw5wMEdQE88UqdCThtZuWi+x6PJ3XuSMy214KlmhM+HKLvvGgJWG9DsfF7ad3WJ76w7+hDy8R+meNYADwvvAZOjy/Iw4AFVZ02ACmSy6qOv2Kl1ZD/scjwJf82WMpCSk7b1x8vJ0tU5TlmaYcaotQeOLb1cwEdlKtf/zwJSE0gX2HVsLmDxOcFv9vhxYQwiDR8q3bJab2d4z9qCyWUafsTVQuFfiX4EUcRcyElyw41XO6amKpIqzsDbHliTC6JPxMZyVjSo40dlfGTWDOOGlH61mr1TitfHddvBwRiOyZSb7exA4Ai3j6cM52SYGWhK/OPHqE1TeSB/TDrW5irqpthwrQ2m7oPOD9TPceUvQEhl1B4oCwzxtaM8JQwSoDW0 uY6MB08c RBClhTB5T0IcY97tKL39Hh39t7CFSYPi6lAWj3o/8WByIz8tpJBHjdFHS5kpNL3fzh+jwGGpTnG9t4VaY4TalUMOx6Q1kSo8n6teFfgvCWH6/qQKqzHDJ6Uny3ruM9QW9OJyF2yEvtQE95TGRor9IsbqOvXjhbtppLwsN5dPZUfr75mQz5ZrwapNZSpPBNYMEUPApVV8C6qbP+qwo2H0Z7IfeCUNW1WL5dWK5SaaSXZUP6qh5P3iDn//Y/IHk6jEhPkpmE3UQH5Ve4R8YUzGtZf3IlBUVcuvJrNnRshfNoFGFpV1aHh9qQhWH62CXoCQJ7ZPiRxmnFzAdTW8+trieTfUjQCxQUzxQTO3P1HFau7Mg2wItVYP2zCpMDl+M/uX2qS6MOqT1uy6IW8psYzS9RyRHkZ+SeN5Wc05Lqiu29XLhrk+07NZnvF2I4c4wCnZI3FgdtdS+bbTrAsNvvzZvDOnmmwCG/js/JKGli6z0fZ+toNQ= 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: On Mon, Aug 5, 2024 at 12:01=E2=80=AFPM Linus Torvalds wrote: > > On Mon, 5 Aug 2024 at 11:11, Jeff Xu wrote: > > > > One thing that you can't walk around is that can_modify_mm must be > > called prior to arch_unmap, that means in-place check for the munmap > > is not possible. > > Actually, we should move 'arch_unmap()'. > I think you meant "remove" > There is only one user of it, and it's pretty pointless. > > (Ok, there are two users - x86 also has an 'arch_unmap()', but it's empty= ). > > The reason I say that the current user of arch_unmap() is pointless is > because this is what the powerpc user does: > > static inline void arch_unmap(struct mm_struct *mm, > unsigned long start, unsigned long end) > { > unsigned long vdso_base =3D (unsigned long)mm->context.vdso; > > if (start <=3D vdso_base && vdso_base < end) > mm->context.vdso =3D NULL; > } > > and that would make sense if we didn't have an actual 'vma' that > matched the vdso. But we do. > > I think this code may predate the whole "create a vma for the vdso" > code. Or maybe it was just always confused. > Agree it is best to remove. > Anyway, what the code *should* do is that we should just have a > ->close() function for special mappings, and call that in > special_mapping_close(). > I'm curious, why does ppc need to unmap vdso ? ( other archs don't have unmap logic.) vdso has .remap, iiuc, that is for CHECKPOINT_RESTORE feature, i.e. during restore, vdso might get relocated after taking from dump. [1] IIUC, vdso mapping doesn't change during the lifetime of the process. Or does it in some user cases ? [1] https://lore.kernel.org/linux-mm/20161101172214.2938-1-dsafonov@virtuoz= zo.com/ > This is an ENTIRELY UNTESTED patch that gets rid of this horrendous wart. > > Michael / Nick / Christophe? Note that I didn't even compile-test this > on x86-64, much less on powerpc. > > So please consider this a "maybe something like this" patch, but that > 'arch_unmap()' really is pretty nasty. > > Oh, and there was a bug in the error path of the powerpc vdso setup > code anyway. The patch fixes that too, although considering the > entirely untested nature of it, the "fixes" is laughably optimistic. > > Linus