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 05B69C02194 for ; Mon, 3 Feb 2025 13:13:02 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 4C2AE280002; Mon, 3 Feb 2025 08:13:02 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 472C4280001; Mon, 3 Feb 2025 08:13:02 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 33A58280002; Mon, 3 Feb 2025 08:13:02 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 1397E280001 for ; Mon, 3 Feb 2025 08:13:02 -0500 (EST) Received: from smtpin18.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 95C9A82810 for ; Mon, 3 Feb 2025 13:03:17 +0000 (UTC) X-FDA: 83078649234.18.34E81EE Received: from mx0a-001b2d01.pphosted.com (mx0a-001b2d01.pphosted.com [148.163.156.1]) by imf09.hostedemail.com (Postfix) with ESMTP id 48DCE140002 for ; Mon, 3 Feb 2025 13:03:15 +0000 (UTC) Authentication-Results: imf09.hostedemail.com; dkim=pass header.d=ibm.com header.s=pp1 header.b=stFvnQWW; spf=pass (imf09.hostedemail.com: domain of agordeev@linux.ibm.com designates 148.163.156.1 as permitted sender) smtp.mailfrom=agordeev@linux.ibm.com; dmarc=pass (policy=none) header.from=ibm.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1738587795; 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=3tOM7qfdbRGNaF0KBXRjbYknH0426yEzofPiLSXB8EQ=; b=nxncmwJJE9R2o8k4+SVKhrqBWapxU6f/QskvcARzFmKaq8wXesPlkhRuxQX1EUSVVg/QEC JGT/M2sXcHPS1PNMZt6JYA8ENTRZjNHKTjSoQ5lZQoLqqM01N8C5uUyWDjrXuNKAslfhjr JJ4CM+rJ28y8cHIG/bPAf5BEgDlrT6M= ARC-Authentication-Results: i=1; imf09.hostedemail.com; dkim=pass header.d=ibm.com header.s=pp1 header.b=stFvnQWW; spf=pass (imf09.hostedemail.com: domain of agordeev@linux.ibm.com designates 148.163.156.1 as permitted sender) smtp.mailfrom=agordeev@linux.ibm.com; dmarc=pass (policy=none) header.from=ibm.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1738587795; a=rsa-sha256; cv=none; b=M6vogjB1j3bEOksMfKjA7LAUdmICsuE74W5cgUZDGej3yRmh+KDpa4sSpIB1v0t/vEgWif RJOCPKnh5G26PzX20kyB1HiCotfyb6lxfGBSMfimO6U+Chp8wQ/h4T02g1lXAmt32mPHoT x8/R5TTw160qCh+GlfnSl4p33lV5/2s= Received: from pps.filterd (m0360083.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.18.1.2/8.18.1.2) with ESMTP id 513BsfX8026545; Mon, 3 Feb 2025 13:03:11 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ibm.com; h=cc :content-type:date:from:in-reply-to:message-id:mime-version :references:subject:to; s=pp1; bh=3tOM7qfdbRGNaF0KBXRjbYknH0426y EzofPiLSXB8EQ=; b=stFvnQWWtt8aokQo5n0Nxy4OH854Hp9IAkZbTscQqZD3De D4LGadADTj6Rw/Cw0BXT17DPs54O/aj2zgQKBKWb1hUVLcjlLFKabZ/vbGdLkgf1 /KCAGyfcfoMkF0jbd/B7tclQNG7dMFsfoeAqWUl3DYVasdomIdKfmVioX10NAW9e 5nKe7GecdU1m0TGn5H9GfeS9OTWnqxeEubib6VDoXyKgDlrh+WmOeXs+Olk/GhGZ atv4AMkTpqzkFen5yjRtTUqI0Rp5zaFxlQkq/gag0TP/a6wzpMqKmfEnoXs+pDsG eoweFOL9pH3QzKyVWaRm8w7KB+FIcKzwBtfSxkbQ== Received: from ppma11.dal12v.mail.ibm.com (db.9e.1632.ip4.static.sl-reverse.com [50.22.158.219]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 44jkv92vtg-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 03 Feb 2025 13:03:10 +0000 (GMT) Received: from pps.filterd (ppma11.dal12v.mail.ibm.com [127.0.0.1]) by ppma11.dal12v.mail.ibm.com (8.18.1.2/8.18.1.2) with ESMTP id 5139BdMM021493; Mon, 3 Feb 2025 13:03:09 GMT Received: from smtprelay05.fra02v.mail.ibm.com ([9.218.2.225]) by ppma11.dal12v.mail.ibm.com (PPS) with ESMTPS id 44j0n162yx-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 03 Feb 2025 13:03:09 +0000 Received: from smtpav01.fra02v.mail.ibm.com (smtpav01.fra02v.mail.ibm.com [10.20.54.100]) by smtprelay05.fra02v.mail.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 513D368255706008 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 3 Feb 2025 13:03:06 GMT Received: from smtpav01.fra02v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 1B0472007C; Mon, 3 Feb 2025 13:03:06 +0000 (GMT) Received: from smtpav01.fra02v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 43E6C2007A; Mon, 3 Feb 2025 13:03:04 +0000 (GMT) Received: from li-008a6a4c-3549-11b2-a85c-c5cc2836eea2.ibm.com (unknown [9.179.20.74]) by smtpav01.fra02v.mail.ibm.com (Postfix) with ESMTPS; Mon, 3 Feb 2025 13:03:04 +0000 (GMT) Date: Mon, 3 Feb 2025 14:03:02 +0100 From: Alexander Gordeev To: Matthew Wilcox Cc: Gerald Schaefer , Heiko Carstens , Vasily Gorbik , Claudio Imbrenda , Christian Borntraeger , linux-mm@kvack.org Subject: Re: [PATCH] s390: Remove PageDirty check inside mk_pte() Message-ID: References: <20250116212338.653160-1-willy@infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-TM-AS-GCONF: 00 X-Proofpoint-GUID: RGP66zyMy7uFK2tmqaPcm9I9F8XHUUaR X-Proofpoint-ORIG-GUID: RGP66zyMy7uFK2tmqaPcm9I9F8XHUUaR X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1057,Hydra:6.0.680,FMLib:17.12.68.34 definitions=2025-02-03_05,2025-01-31_02,2024-11-22_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 bulkscore=0 mlxlogscore=419 priorityscore=1501 impostorscore=0 mlxscore=0 suspectscore=0 malwarescore=0 clxscore=1015 lowpriorityscore=0 spamscore=0 phishscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.19.0-2501170000 definitions=main-2502030097 X-Rspamd-Queue-Id: 48DCE140002 X-Stat-Signature: eohgz8j7xi9tnmd1riq3ni1pgjoja3wo X-Rspamd-Server: rspam08 X-Rspam-User: X-HE-Tag: 1738587795-671820 X-HE-Meta: U2FsdGVkX19WlmxiGS2lLv4JJRHvFmkeo1sILLaM3EQmkzTytFEsCybvK4fDi7pyQkTaAdwSF2+2onj/21mATPboUoXrSjJXGoqErYBDx3AU5aDgccsnZJu+aUnbuWzdgopZsirWDx15u0KcTCP3e7fRLOpv7hX0QXyYqFAD4EJ1BiG6s119SImrrS4EP1mz/VsE38LXP0nfTQMGVRpz1aKvP6GRt33ZQMivmbtrVbgI4kBCYNSLcfiMuWypkf4Q05xz40S21ue6h+7AxUTbphTBwnQj7pGvB9O7D7NzdfaCWL8WBer9TO3vHB834ke0jop5/F49fc+jMtc31v25XLz9WKwY9/Y5Diu7vJY3iVfFhxsmtgqOBR9y3fSL/u2fqRnQjOmd9KkVef3vGVpno7hiku/2D/LrNs5/5njYUmxNJ3m0TRaRUgaNtnI9siPZYjgZUFNz+pvNmTViuUSg11lmdgPr2UNvePvH4SVsoVLwqV0H/qLJbVP6ahuPwkZC46AcykdPi7UQEi24rd3DZgohXDo/FrPzZIDFw4nV5mfsxodbDMeeoO2hcogrd3jKsa0pJvcwkaB9J2hoxck7I/qChvsbTDMiUSobQM4Tc9G05ivjuHoLHIml4ZhZ12vbLQkz5LviCjVUxw7uDreYX6uKFrW6oL2u0eLgBWENsVdetjrga4nerLrZA8nznRybIlgph3V+qi/VgPAy65Fuo1/fweKpQi80opJvvkOnUApiOKFxykvEPIkwbghHU5+QHMObjQ/udm6l8ybbwKSNKtHc+nAr97P2JcAj/ExH5ILFUN+Q0Yo2DdpLITZJ8azJdiCqBMpm/BWy0ekrLFdmKzyeOB4kjdnXZtRO2GPdjYonH/DhRuP6u7hq/t0CYkDubG4OmFHwhJR8uqpseqKRQoD/Z2ZrxLdkuMLH/ef4vO9DuZepv/xPWeIfsoVuon4uxgbeMVbMTD3oxD9j3BK I6wkWZot 8K2ENyPU2KUatIsrN4XbwcF/I7VQc8QoPsfeAKZ8XO0vU8QV2xdgyRGK3hJkccNmFGhBNh2ojk1kvI8pGNi46ppQEKLUPG+iCTvZyTEwdai5G2pbwQJIIk+QwUYOtId9+MYfqRyOS3asOFjLHXpNVnSTRjCELhxkG5A9CDjXoQa/hhZ3SkQXGEW8TBTlSa/IAwn53kRuNuMZwOKi+PnCmFRbwLhS2Xkz5FfuhyG6jWPiK4yMoOAgVOtj5/obFXSMO7uXGpZOT7KJ+JEA02BP6WdCFmfZh5TPEpi2VIMKS3ibV5LqB23FHyEkVjZgezwZ6/WR5X4uf4+5p9R8E0CccLanHXWQcYK4LmXQqXuGyUpXv8+7uu/3vezHb01Wp2lR4Oi7gEIT/2XWidOI= X-Bogosity: Ham, tests=bogofilter, spamicity=0.001676, 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 Thu, Jan 30, 2025 at 10:12:48PM +0000, Matthew Wilcox wrote: > On Mon, Jan 20, 2025 at 05:39:43PM +0100, Alexander Gordeev wrote: > > Despite the commit 75edd345e8ed claim above I still observed that a read > > access to shmem page could end up in creation of a dirty PTE: > > > > handle_pte_fault() -> do_pte_missing() -> do_fault() -> > > do_read_fault() -> finish_fault() -> set_pte_range() -> mk_pte() > > > > Our internal discussion (among other things) ended up in a need to really > > understand where the faults are coming from. > > > > Further, a cursory LTP test was showing ~18K page faults increase, which > > I did not confirm. That is the first thing I will re-do. > > > > Whether this change is a pre-requisite for something or what is your aim > > wrt to this patch? > > One of the things that needs to happen for the splitting of struct page > and struct folio is the removal of all '&folio->page'. Most are in > compatibility code or code that is being transitioned and can safely be > ignored. One of the places that needs to be changed is: > > entry = mk_pte(&folio->page, vma->vm_page_prot); > (there's a few places like this). > > I believe we need a folio_mk_pte(), and I don't want to define it for > each architecture. I don't even want to have a default implementation > and allow arches to override. I guess, folio_mk_pte() would then still call arch-specific mk_pte()? > So the question becomes whether to: > > (a) Get rid of the conditional pte_mkdirty() entirely (this trial > balloon) > (b) Put it in folio_mk_pte() for everybody, not just s390 > (c) Put it in set_pte_range() as David suggested. > > It's feeling like (c) is the best idea. I will check option (c) Thanks!