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 3DC4DC61DA3 for ; Fri, 24 Feb 2023 04:42:11 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A0BE36B007B; Thu, 23 Feb 2023 23:42:10 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 994B36B007D; Thu, 23 Feb 2023 23:42:10 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 79A826B007E; Thu, 23 Feb 2023 23:42:10 -0500 (EST) 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 607AC6B007B for ; Thu, 23 Feb 2023 23:42:10 -0500 (EST) Received: from smtpin28.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 2AFEDABCA9 for ; Fri, 24 Feb 2023 04:42:10 +0000 (UTC) X-FDA: 80500938420.28.E0295C4 Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by imf26.hostedemail.com (Postfix) with ESMTP id 1D2D7140013 for ; Fri, 24 Feb 2023 04:42:04 +0000 (UTC) Authentication-Results: imf26.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=g7MEFQwd; spf=pass (imf26.hostedemail.com: domain of fengwei.yin@intel.com designates 192.55.52.115 as permitted sender) smtp.mailfrom=fengwei.yin@intel.com; arc=reject ("signature check failed: fail, {[1] = sig:microsoft.com:reject}"); dmarc=pass (policy=none) header.from=intel.com ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1677213725; 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=KUqJenOkPtOn019Q7a9oMnTWTY3rarbyFH8ojJRdTGI=; b=P1vkBTEKbsZ7QC69exdkYmR4SsG4ASX/oqGT7IsRff0QFnS9oXswv7MHT124uzTNrGClne oFNVX2eyyPq5KWYydlCV9hYyiTznHT55wiHlHayW23DLBNCIs8HF+KBGUSGvY31VLzAvUx PxUCmcPI6w9MZoHMkmMl3Pvj9IEPLi4= ARC-Authentication-Results: i=2; imf26.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=g7MEFQwd; spf=pass (imf26.hostedemail.com: domain of fengwei.yin@intel.com designates 192.55.52.115 as permitted sender) smtp.mailfrom=fengwei.yin@intel.com; arc=reject ("signature check failed: fail, {[1] = sig:microsoft.com:reject}"); dmarc=pass (policy=none) header.from=intel.com ARC-Seal: i=2; s=arc-20220608; d=hostedemail.com; t=1677213725; a=rsa-sha256; cv=fail; b=oYVuoHhQxX33RDYi0qCZMmVjnLK+WVwwgSN5b0hhIqEYe0+KZ6yXTn2aiHdmdlXIUXaKxJ m3+zPOVYnkJ40M3qWp88QU/09hmMIIPHI4zMVFS9w+5gH7UOb4U7cNqFAJigA8uwwmJcU9 lgavmMgq15YX1LYf+0DOzrVsfjkRSSA= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1677213725; x=1708749725; h=message-id:date:subject:to:cc:references:from: in-reply-to:content-transfer-encoding:mime-version; bh=x3dis1BqixbovqKs9C2FNEP67NPjq/uml27J9h3jPEI=; b=g7MEFQwd1t5b/vvxpTEUDzP/t9T/OReokG/e+Wod0NhMGLDsZr1uELsZ Ue4CGKupkQ7bEUIzMdKhJdn9KEkRdENCbjlVIt87wA5us0froDuMiZdVo QKptHrA0cd2RA2zULF2KMv349f6e50BmxFIrsnmUaYzvJ6c/UySDapRg5 JJ+JfM/M8UGUYp5+Jhb8fN8l3WRwJP+C+7HMIFIdumEQ4973YKOZMIHbH WfMrVPQR0N+hYzuUisjMViVMvIvpgjgsPiMIvN2zW8390QCwXTCW+QpFC Dn1odg30KvQztGNx2OedYcKfgTTcvgv/zjsXw/WkMQOXX/yiYsMIEg8Ol Q==; X-IronPort-AV: E=McAfee;i="6500,9779,10630"; a="333401714" X-IronPort-AV: E=Sophos;i="5.97,322,1669104000"; d="scan'208";a="333401714" Received: from orsmga006.jf.intel.com ([10.7.209.51]) by fmsmga103.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 23 Feb 2023 20:42:03 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6500,9779,10630"; a="650228948" X-IronPort-AV: E=Sophos;i="5.97,322,1669104000"; d="scan'208";a="650228948" Received: from orsmsx601.amr.corp.intel.com ([10.22.229.14]) by orsmga006.jf.intel.com with ESMTP; 23 Feb 2023 20:42:02 -0800 Received: from orsmsx611.amr.corp.intel.com (10.22.229.24) by ORSMSX601.amr.corp.intel.com (10.22.229.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.16; Thu, 23 Feb 2023 20:42:02 -0800 Received: from orsmsx610.amr.corp.intel.com (10.22.229.23) by ORSMSX611.amr.corp.intel.com (10.22.229.24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.16; Thu, 23 Feb 2023 20:42:02 -0800 Received: from orsedg603.ED.cps.intel.com (10.7.248.4) by orsmsx610.amr.corp.intel.com (10.22.229.23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.16 via Frontend Transport; Thu, 23 Feb 2023 20:42:02 -0800 Received: from NAM11-CO1-obe.outbound.protection.outlook.com (104.47.56.169) by edgegateway.intel.com (134.134.137.100) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2507.16; Thu, 23 Feb 2023 20:42:01 -0800 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=bAFI9iFNcOdKNDnGuIeOAbu51TqFKgBzdWjFnH6FqECWHTrmdFiwcPcCzqne2RhXGB7BkLDUCZYvDw7J0T4aT+5sKSJ8Zeg1cxqGLcKs2ibPwhG22cTx3qm3sel4lrbUxbyfgbndLI+ZVyd4VEmtHria2E2+6M8qffn7UTsL4KMdQ1v7FSr/1IAto8ADYuiEMYh+N7t1vbcVnqdR0S/iMIXqcJQIjN7UJVWd7pJ+UV+Prh7c4fPp+gwcDvIvbHgwQAqD5h/QNXjRJe3ZaG61V2nNKiUrfY4RLzx4tNIQkLgSqOmNv52sHxuIPGWs/hdZplvCD5kGf8Y1kKymlr1dMw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=KUqJenOkPtOn019Q7a9oMnTWTY3rarbyFH8ojJRdTGI=; b=cxAQv+PzZkzj/DEqsdnFte5t7t3XdT7CGu+gzTnIpoPulDSH32L9QRnSIuu7pWqiVtXH4GmucWkAFgdEKHPAkcNdXZ033E4WitU3wPA36gSmUxMVh5Hsxcs+iMKohbWTlL+BuZEvtZgeuzsyPrOL3n/qBdG0hqhY5Pmo/RCakboUieeMFI3lf1z/s8loYqkMd2zMSSJLpgVAGIZ9VCyOQnvMgZaaJiVnfNsvMs81q/OgJ8szVWhk6BkJA15KhLo6Gfkr+o3wMSVhU7R+DOreqRpw/jzBY45z0CbOihFz28CMstOopvNo/M/c+SSHw/pV7Op3uEL51sCVumj7Zp8O1w== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=intel.com; dmarc=pass action=none header.from=intel.com; dkim=pass header.d=intel.com; arc=none Received: from CO1PR11MB4820.namprd11.prod.outlook.com (2603:10b6:303:6f::8) by SA2PR11MB4777.namprd11.prod.outlook.com (2603:10b6:806:115::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6134.24; Fri, 24 Feb 2023 04:41:59 +0000 Received: from CO1PR11MB4820.namprd11.prod.outlook.com ([fe80::8073:f55d:5f64:7c6]) by CO1PR11MB4820.namprd11.prod.outlook.com ([fe80::8073:f55d:5f64:7c6%8]) with mapi id 15.20.6134.023; Fri, 24 Feb 2023 04:41:59 +0000 Message-ID: Date: Fri, 24 Feb 2023 12:41:49 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Firefox/102.0 Thunderbird/102.8.0 Subject: Re: [PATCH 1/5] rmap: move hugetlb try_to_unmap to dedicated function Content-Language: en-US To: =?UTF-8?B?SE9SSUdVQ0hJIE5BT1lBKOWggOWPoyDnm7TkuZ8p?= CC: Matthew Wilcox , "linux-mm@kvack.org" , "akpm@linux-foundation.org" , Sidhartha Kumar , Mike Kravetz , Jane Chu References: <20230223083200.3149015-1-fengwei.yin@intel.com> <20230223083200.3149015-2-fengwei.yin@intel.com> <20230224025119.GA1911853@hori.linux.bs1.fc.nec.co.jp> From: "Yin, Fengwei" In-Reply-To: <20230224025119.GA1911853@hori.linux.bs1.fc.nec.co.jp> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-ClientProxiedBy: SG2PR04CA0165.apcprd04.prod.outlook.com (2603:1096:4::27) To CO1PR11MB4820.namprd11.prod.outlook.com (2603:10b6:303:6f::8) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CO1PR11MB4820:EE_|SA2PR11MB4777:EE_ X-MS-Office365-Filtering-Correlation-Id: e0f9661b-a414-457d-74d8-08db16217729 X-LD-Processed: 46c98d88-e344-4ed4-8496-4ed7712e255d,ExtAddr X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: 4OAkZsrNQSXI+WWA/r8BHNfd188NOZUfyLFy1MoMyUAMnXL5pj+QBut0v2PrxjP3WTg8UI6Swg9BJZO6BGSjTMUNeTPsnXP+xJFAzs7DrzJjzvlsy6ZJ19Ni9uHT0YkEN4skBRKqq5quxcGwp2jBJFX3WIOoe+HPeopyy0aMADtjg/PchCz/BJ5wywW9PWpmEm7PU1OObHprfayE87IrRSg/FwR/YBkGmDE562Zm27/+hmd+QPL1sz8jcjPyN8nYrLldk+Cb9UqKXyurJbYfQgUmRmjqiqcH5jiZ7CpLoXP5/7LBfv5+ozidF/dqoeqCcHofCxVjp26WGuFE6ShdQ4R3K+ELVLdZih92X+tIvaNXYyKvl1ipgxGrnPG0WS8fnwtTu/BE3iY926FkPh6dp7s1jtIzhfbszZdKNkNEstJUnHBi58GcyCRkfDIrUVraYhnt8TpAc1TLNFjXDApDkbGVpqX3/D6nZTmC8mt6kNBG8Qwu4r9UKaYb9E6HrcENFTJSS6IevRcZ4MtW2uiN140noNSpfBmorPRdSbqJl9Xd7Zcuwt2OT0ibVfiP3UAS0HhtdSMgPOWovM02+6MisLdnI+uCA3v879VcDPxIZahwvjmLohuHban+MBCeRsmW5YwOdExuXWaRq22ts6M7VKnmWUjUDyTHOC0c55Vs7juVH8M69QijVctju1WOKzIdJrB/fiAJofE/1bFBP12gw47Qy8zfoRWSYFBrMCeXOeE= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CO1PR11MB4820.namprd11.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230025)(376002)(396003)(136003)(39860400002)(366004)(346002)(451199018)(86362001)(478600001)(41300700001)(6486002)(31686004)(2616005)(4326008)(66946007)(2906002)(83380400001)(316002)(8936002)(6916009)(5660300002)(6512007)(8676002)(66556008)(66476007)(31696002)(186003)(54906003)(26005)(6506007)(53546011)(38100700002)(6666004)(36756003)(82960400001)(45980500001)(43740500002);DIR:OUT;SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?ZEpIV2tQYXgrNnNWby9oQ1k2TUlRU2lTUW42MU53UFpueiszNFQ2bUw3bUJu?= =?utf-8?B?SE1sMVVLMXdPM1M0clJoRml4TmNDc2t5emUyaHNiRzBBSjFDMHdqNmRkYTRw?= =?utf-8?B?S0x0citrZkh2QWUyRnBudWpzQ2Z3ZzB4MVZ6cG9FcWQxUUJGWmFuclVJcXdB?= =?utf-8?B?Ulo5SjNGUEY5Qys0cm5hN1NvUFBCRFZnNjdwUnFKbUZXcGlKdkVnUEZMc3lW?= =?utf-8?B?ZXZvU3VEM2swSHQ5TzRSaEVzSDlEQml5elVPdCs3a1pzWEJQeVFDOTlxcmlK?= =?utf-8?B?Ry9FNWhBN0NER0EvdzJWVEdTUWlCNjYzczhURERZWmJla0pyeFVMWVd0TVFO?= =?utf-8?B?U0FiT1lnM3RJRHlDZWZUa0NxKzJ1UUJ6L25pa0lxb2c4RTdqdjhmRVZzbWky?= =?utf-8?B?QmpNa1g5SndZWFlqVHJoU29vRWlYbmVzNGVRRjFhNHVkUFZjYmtlRFA4cW1N?= =?utf-8?B?MzdrdW5pZzdDcW1uRHF1STMxaUNUTzdCY1BpY3NjYTNRTVFMSXdTdlRJMXd3?= =?utf-8?B?clJ3Mmx5ak94NlpsVUR1c2pwbUlBbXNzL3RweHBIU3FLdFNnRjEwcVplWFdw?= =?utf-8?B?QmgxbjN5d3BaanV6NThXVnZmbUwwb1hRY0RxaG5LZG12ZElkM2RrQVRHRTNp?= =?utf-8?B?OWtadHJ4V2pnUyswbGh1OHRmb1RVcm82d0JIdE1ScTVJYXJzNGRHNDRPdVdt?= =?utf-8?B?S3pnMFJ6U1d6b2dua2lNWTZtNDdISmFVTUhCNDlJM2lncnNNa2s1TkVtZmFq?= =?utf-8?B?U0dtdTVxM3hQQVdObDQxRkZ5SFA0dHF3V1hvV2dRMDFTR1pRMDc0Zi9GY09H?= =?utf-8?B?RWIrb2xXekd2SGI0aVBtM1FVaU9qTFNjZzVpbjVndVVwM09KSkllekpNM0Vr?= =?utf-8?B?VVBCV2xZV0I5ODcxTFZtUXMzQXRraWVIV3A3ZHpiTUxqOFJraklYSnBTR015?= =?utf-8?B?dURlQTJiWjAzMS9pWVFNZVZVNGFlMXdmNnJlWjZmbEg0NlBCWXpPRGtnSkl2?= =?utf-8?B?N1BVUWZoNzlvZGZGYTZ6NTc1cHpaNWt5d0d5Y2hYUzZUS2NwRkI0Vm9BZERP?= =?utf-8?B?Mk00ZytTT2U3TXh4VlBUcGtRY1prYVRwY21ncktqVHZkcHN5K1VGRlg3ZVpE?= =?utf-8?B?blRzbDFtUFYxeWpEYngxTlIzVkkvNGdlWjNiSm1yell3SXBua0NFcVdONGFh?= =?utf-8?B?eWtDekZuVDd0RW5hdWF0TE5EMW5iMVhFU3lRWlRBUHlIYitwWW4vcjFZeDAv?= =?utf-8?B?UDYzTW56VTM5YkZqdVU0Umx2VkZ2NGJFNDBwS0NrWk5mOFJtYVVlZDdyY0Va?= =?utf-8?B?TXpyTHYxc3pENGNxb1FLK3Q2S0FxY2xFTFVZTVlXOHhyeDgzSnF3WG5iOXFY?= =?utf-8?B?L3FjblJJeDhGMmo3RHRycUNUUDIzMjB2c1NxdlRQd2Q5WXRYd2ZHQXo5WVpG?= =?utf-8?B?bmZQaDdQSnNkOVFzTERrNlV2YlY1UHkvUjUwemNQTUhXOThGazdhZjR6ejZW?= =?utf-8?B?Mi9IdFVsU3YvWGU5eVAxNVVMeWhVMUxvTkxpV3RnQ1hobW1zUHEzOFc3WFpl?= =?utf-8?B?MzB6WSt1cFBMR095M0xqeWtIMENLYkxkWlBoZlBmdHM0N092VGRGczN5MnRr?= =?utf-8?B?czlvK1dzNk4xcHRob0M3MWdTMXkwUmlLU0RzZnBkaUhPa3BPdlVMVmVPQ3Vn?= =?utf-8?B?MnJGWUFmc3VvNDdMOURTbjBoNXVtblNyWURHS005Y2U2UTUrWlQ1WHptYTVB?= =?utf-8?B?SFNtUXF5dHF1S0N3bUVUbFI0Wm5DdEhuSUVVcm1lT2pzUDVFLzg5RXVlcllx?= =?utf-8?B?U200ckx4RUxHYXZKQUFKTDF3aFJzZE9CU1FIbXphVG04UjhtV1dpWU1wazdh?= =?utf-8?B?aHkwc203KzFEVnc3ZWlGdXJwSUliOGFJYVVseDZaMWRiWHNPbTNPZWY4VmZx?= =?utf-8?B?dXZsVDhsSDU3RWNxOE9OKzM0d0V3ZXdzSm1PM0tPVXVndDRaYmF0RzVGSDBl?= =?utf-8?B?MEhEU2sxZkpDbHFmSytjWWtKZm1zcWl3UVorMTFMaHJZMWlwQ2hwc3l5ZCs0?= =?utf-8?B?M214dGxJSXMrdmRTaGVSb0p6L3U3US9vQ2NYRm9OYjhsdm1nTUp0YVBLZktO?= =?utf-8?B?a0E3djdaaE8wQ0tqaFJ1S2JJdXVSQXZHdGlHNE5xSGVJQ0pvdGZwbDRIbW9o?= =?utf-8?B?cmc9PQ==?= X-MS-Exchange-CrossTenant-Network-Message-Id: e0f9661b-a414-457d-74d8-08db16217729 X-MS-Exchange-CrossTenant-AuthSource: CO1PR11MB4820.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 24 Feb 2023 04:41:59.6212 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 46c98d88-e344-4ed4-8496-4ed7712e255d X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: /CaPt4rBFguYxZK5l0lvhMnZ9TuqLgalOipviss6FOAofqNnYfn6oblmH9P1huyvZgRE3KMNLTvyLZdQOl7Rzw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA2PR11MB4777 X-OriginatorOrg: intel.com X-Rspamd-Queue-Id: 1D2D7140013 X-Stat-Signature: c47b5goupu41n1if73rhj8h7ifuu7qkp X-Rspam-User: X-Rspamd-Server: rspam08 X-HE-Tag: 1677213724-820534 X-HE-Meta: U2FsdGVkX1+6dkCXsrizPURQ/4rBgQVoXEU/b9oFSjVtFpgYFROMYSIw8I1RrWxypkDGSSuasGmuH/u6fCyjVh4gyuo7oNBCFazCT6syqjGEsvLm2D5jGFI0UScIqc6+isq3BCDF/kzl6rIihLO2NHixcimYWeT7tq4hxwpDtRxw8oXOK5qzSxsBVXNvCsh7lmgvOnXR4ADXmdJpVXJYNRFxRQrZnbdYDGDWx4/gD2x7YBbkgxwShiwx0em4TIW9ViEMZPKH0yeAnF3/SWIg781XRhFiHuxdwXNFvpPZI82ui82zXyXM0BEiGZB8XTkCvS/fCIWC6NF4HGt8JibHA9p+TpFZtGSI3I8UoqPPYSqhLOmfEC3NMRrB9jbr5dswVLKrAMAeoFMYGW++3or+khMIMS1b2kbK4yw8US1hxkWFHTU3O5a4caqMphKJW2RdF05XycPph6dnOC8ul0PlWsHKnLBPVLj7Tu3d9Dkzq0NF/OHL9JwZzqTuepEycHc3GdIUY8RtE/6sljwFP3a4x5oLZyEPJVJel5te2Qhkv1mirDKozmWI6WcmTCdDsvRKhysiEThEXzGENMAs31lyid3ZwiJBHCFKSdlDSnafE/YaXlvb6ECUxhisr177eheho8qg6AFxLXJPBNAe221LrLJlfXYAPR92xB6tCZqaWGB1k2JyUEqNBTl989E6wGyaHAyHeZHK+lLhB6M9QPnlNN3YBxqYfWr6xsPBRCkb9KlOHH6iujMdBe3zz6HZHJlKtDZtSAi3J7BYK4SfTVGBG6FRhqbBDGPCa+jX8ZfFEY49w2P7bIeIsEthroY+iEOh70YrVfZWb1jfGj5/b51SDvPOAyxVq5+vx+CtxivOxXOmZoZaYVd6xIPlvehKHMXVGt8OlixvP5HBR0gyB7cOFFEU3XCkRleSVzXIMJLcEBf8MbsL8ZK1pEY0Szu8OwuUgnFWp7k/6JJEbvOmPic NVifdE6P UkzvZ6oFg+TQsgEkOX07wigC9cuKeUCjwFmGXXC1mYQkiEtOVASX3yx0yAIaV40MxscYV2K4oA6wmTM5++kSs45y8QbS7F40n2ClpvfZ0zGgxjvPF3oHBJF6w8b9aWRxPSH6OLdwIT9LopasQyITRZSCqXo9uH4S2CbF1sNuK6tpn6Q2/Ux6+Ow3PSKMJ1GyEsaI4AiwJrxdtHc4QBjHu0QMaP3+0PHQWKshih2rwkI3KyYbxdV9/HpZzkhunt/IJswrFP/crO2P9ywGPPNFZCWwMVFKx8uO2oOhfusKTcBoLe/GRg1PBo7x5nZV/oOMht+/XjoNJtlhF2YwZeV7U9VktUTKjrx//ks93wqQ4+OESXvHFOfJ4gNs8IjxXgDZ0rJPePOWa8wcGgb2jEHiSVUNinw== 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: On 2/24/2023 10:51 AM, HORIGUCHI NAOYA(堀口 直也) wrote: > On Thu, Feb 23, 2023 at 05:28:10PM +0000, Matthew Wilcox wrote: >> On Thu, Feb 23, 2023 at 04:31:56PM +0800, Yin Fengwei wrote: >>> It's to prepare the batched rmap update for large folio. >>> No need to looped handle hugetlb. Just handle hugetlb and >>> bail out early. >>> >>> Almost no functional change. Just one change to mm counter >>> update. >> >> This looks like a very worthwhile cleanup in its own right. Adding >> various hugetlb & memory poisoning experts for commentary on the mm >> counter change (search for three asterisks) >> >>> Signed-off-by: Yin Fengwei >>> --- >>> mm/rmap.c | 205 +++++++++++++++++++++++++++++++++--------------------- >>> 1 file changed, 126 insertions(+), 79 deletions(-) >>> >>> diff --git a/mm/rmap.c b/mm/rmap.c >>> index 15ae24585fc4..e7aa63b800f7 100644 >>> --- a/mm/rmap.c >>> +++ b/mm/rmap.c >>> @@ -1443,6 +1443,108 @@ void page_remove_rmap(struct page *page, struct vm_area_struct *vma, >>> munlock_vma_folio(folio, vma, compound); >>> } >>> >>> +static bool try_to_unmap_one_hugetlb(struct folio *folio, >>> + struct vm_area_struct *vma, struct mmu_notifier_range range, >>> + struct page_vma_mapped_walk pvmw, unsigned long address, >>> + enum ttu_flags flags) >>> +{ >>> + struct mm_struct *mm = vma->vm_mm; >>> + pte_t pteval; >>> + bool ret = true, anon = folio_test_anon(folio); >>> + >>> + /* >>> + * The try_to_unmap() is only passed a hugetlb page >>> + * in the case where the hugetlb page is poisoned. >>> + */ >>> + VM_BUG_ON_FOLIO(!folio_test_hwpoison(folio), folio); >>> + /* >>> + * huge_pmd_unshare may unmap an entire PMD page. >>> + * There is no way of knowing exactly which PMDs may >>> + * be cached for this mm, so we must flush them all. >>> + * start/end were already adjusted above to cover this >>> + * range. >>> + */ >>> + flush_cache_range(vma, range.start, range.end); >>> + >>> + /* >>> + * To call huge_pmd_unshare, i_mmap_rwsem must be >>> + * held in write mode. Caller needs to explicitly >>> + * do this outside rmap routines. >>> + * >>> + * We also must hold hugetlb vma_lock in write mode. >>> + * Lock order dictates acquiring vma_lock BEFORE >>> + * i_mmap_rwsem. We can only try lock here and fail >>> + * if unsuccessful. >>> + */ >>> + if (!anon) { >>> + VM_BUG_ON(!(flags & TTU_RMAP_LOCKED)); >>> + if (!hugetlb_vma_trylock_write(vma)) { >>> + ret = false; >>> + goto out; >>> + } >>> + if (huge_pmd_unshare(mm, vma, address, pvmw.pte)) { >>> + hugetlb_vma_unlock_write(vma); >>> + flush_tlb_range(vma, >>> + range.start, range.end); >>> + mmu_notifier_invalidate_range(mm, >>> + range.start, range.end); >>> + /* >>> + * The ref count of the PMD page was >>> + * dropped which is part of the way map >>> + * counting is done for shared PMDs. >>> + * Return 'true' here. When there is >>> + * no other sharing, huge_pmd_unshare >>> + * returns false and we will unmap the >>> + * actual page and drop map count >>> + * to zero. >>> + */ >>> + goto out; >>> + } >>> + hugetlb_vma_unlock_write(vma); >>> + } >>> + pteval = huge_ptep_clear_flush(vma, address, pvmw.pte); >>> + >>> + /* >>> + * Now the pte is cleared. If this pte was uffd-wp armed, >>> + * we may want to replace a none pte with a marker pte if >>> + * it's file-backed, so we don't lose the tracking info. >>> + */ >>> + pte_install_uffd_wp_if_needed(vma, address, pvmw.pte, pteval); >>> + >>> + /* Set the dirty flag on the folio now the pte is gone. */ >>> + if (pte_dirty(pteval)) >>> + folio_mark_dirty(folio); >>> + >>> + /* Update high watermark before we lower rss */ >>> + update_hiwater_rss(mm); >>> + >>> + if (folio_test_hwpoison(folio) && !(flags & TTU_IGNORE_HWPOISON)) { >>> + pteval = swp_entry_to_pte(make_hwpoison_entry(&folio->page)); >>> + set_huge_pte_at(mm, address, pvmw.pte, pteval); >>> + } >>> + >>> + /*** try_to_unmap_one() called dec_mm_counter for >>> + * (folio_test_hwpoison(folio) && !(flags & TTU_IGNORE_HWPOISON)) not >>> + * true case, looks incorrect. Change it to hugetlb_count_sub() here. >>> + */ >>> + hugetlb_count_sub(folio_nr_pages(folio), mm); > > I have no objection to this change (moving hugetlb_count_sub() outside the > if), but I have a question related to this. > > Generally TTU_IGNORE_HWPOISON is used to control the pte-conversion based > on page dirtiness. But actually what it depends on is whether data lost > happens when the page is forcibly dropped. And for hugetlb pages, that's > true regardless of PageDirty flag on it. > So I think we can assume that try_to_unmap_one_hugetlb() is called with > TTU_IGNORE_HWPOISON clear. So maybe we don't need the if-check? Thanks a lot for detail explaination. I will remove the if check if no object from other reviewer. Regards Yin, Fengwei > > Otherwise, the cleanup looks good to me. > > Thanks, > Naoya Horiguchi > >>> + >>> + /* >>> + * No need to call mmu_notifier_invalidate_range() it has be >>> + * done above for all cases requiring it to happen under page >>> + * table lock before mmu_notifier_invalidate_range_end() >>> + * >>> + * See Documentation/mm/mmu_notifier.rst >>> + */ >>> + page_remove_rmap(&folio->page, vma, folio_test_hugetlb(folio)); >>> + if (vma->vm_flags & VM_LOCKED) >>> + mlock_drain_local(); >>> + folio_put(folio); >>> + >>> +out: >>> + return ret; >>> +} >>> + >>> /* >>> * @arg: enum ttu_flags will be passed to this argument >>> */ >>> @@ -1506,86 +1608,37 @@ static bool try_to_unmap_one(struct folio *folio, struct vm_area_struct *vma, >>> break; >>> } >>> >>> + address = pvmw.address; >>> + if (folio_test_hugetlb(folio)) { >>> + ret = try_to_unmap_one_hugetlb(folio, vma, range, >>> + pvmw, address, flags); >>> + >>> + /* no need to loop for hugetlb */ >>> + page_vma_mapped_walk_done(&pvmw); >>> + break; >>> + } >>> + >>> subpage = folio_page(folio, >>> pte_pfn(*pvmw.pte) - folio_pfn(folio)); >>> - address = pvmw.address; >>> anon_exclusive = folio_test_anon(folio) && >>> PageAnonExclusive(subpage); >>> >>> - if (folio_test_hugetlb(folio)) { >>> - bool anon = folio_test_anon(folio); >>> - >>> + flush_cache_page(vma, address, pte_pfn(*pvmw.pte)); >>> + /* Nuke the page table entry. */ >>> + if (should_defer_flush(mm, flags)) { >>> /* >>> - * The try_to_unmap() is only passed a hugetlb page >>> - * in the case where the hugetlb page is poisoned. >>> + * We clear the PTE but do not flush so potentially >>> + * a remote CPU could still be writing to the folio. >>> + * If the entry was previously clean then the >>> + * architecture must guarantee that a clear->dirty >>> + * transition on a cached TLB entry is written through >>> + * and traps if the PTE is unmapped. >>> */ >>> - VM_BUG_ON_PAGE(!PageHWPoison(subpage), subpage); >>> - /* >>> - * huge_pmd_unshare may unmap an entire PMD page. >>> - * There is no way of knowing exactly which PMDs may >>> - * be cached for this mm, so we must flush them all. >>> - * start/end were already adjusted above to cover this >>> - * range. >>> - */ >>> - flush_cache_range(vma, range.start, range.end); >>> + pteval = ptep_get_and_clear(mm, address, pvmw.pte); >>> >>> - /* >>> - * To call huge_pmd_unshare, i_mmap_rwsem must be >>> - * held in write mode. Caller needs to explicitly >>> - * do this outside rmap routines. >>> - * >>> - * We also must hold hugetlb vma_lock in write mode. >>> - * Lock order dictates acquiring vma_lock BEFORE >>> - * i_mmap_rwsem. We can only try lock here and fail >>> - * if unsuccessful. >>> - */ >>> - if (!anon) { >>> - VM_BUG_ON(!(flags & TTU_RMAP_LOCKED)); >>> - if (!hugetlb_vma_trylock_write(vma)) { >>> - page_vma_mapped_walk_done(&pvmw); >>> - ret = false; >>> - break; >>> - } >>> - if (huge_pmd_unshare(mm, vma, address, pvmw.pte)) { >>> - hugetlb_vma_unlock_write(vma); >>> - flush_tlb_range(vma, >>> - range.start, range.end); >>> - mmu_notifier_invalidate_range(mm, >>> - range.start, range.end); >>> - /* >>> - * The ref count of the PMD page was >>> - * dropped which is part of the way map >>> - * counting is done for shared PMDs. >>> - * Return 'true' here. When there is >>> - * no other sharing, huge_pmd_unshare >>> - * returns false and we will unmap the >>> - * actual page and drop map count >>> - * to zero. >>> - */ >>> - page_vma_mapped_walk_done(&pvmw); >>> - break; >>> - } >>> - hugetlb_vma_unlock_write(vma); >>> - } >>> - pteval = huge_ptep_clear_flush(vma, address, pvmw.pte); >>> + set_tlb_ubc_flush_pending(mm, pte_dirty(pteval)); >>> } else { >>> - flush_cache_page(vma, address, pte_pfn(*pvmw.pte)); >>> - /* Nuke the page table entry. */ >>> - if (should_defer_flush(mm, flags)) { >>> - /* >>> - * We clear the PTE but do not flush so potentially >>> - * a remote CPU could still be writing to the folio. >>> - * If the entry was previously clean then the >>> - * architecture must guarantee that a clear->dirty >>> - * transition on a cached TLB entry is written through >>> - * and traps if the PTE is unmapped. >>> - */ >>> - pteval = ptep_get_and_clear(mm, address, pvmw.pte); >>> - >>> - set_tlb_ubc_flush_pending(mm, pte_dirty(pteval)); >>> - } else { >>> - pteval = ptep_clear_flush(vma, address, pvmw.pte); >>> - } >>> + pteval = ptep_clear_flush(vma, address, pvmw.pte); >>> } >>> >>> /* >>> @@ -1604,14 +1657,8 @@ static bool try_to_unmap_one(struct folio *folio, struct vm_area_struct *vma, >>> >>> if (PageHWPoison(subpage) && !(flags & TTU_IGNORE_HWPOISON)) { >>> pteval = swp_entry_to_pte(make_hwpoison_entry(subpage)); >>> - if (folio_test_hugetlb(folio)) { >>> - hugetlb_count_sub(folio_nr_pages(folio), mm); >>> - set_huge_pte_at(mm, address, pvmw.pte, pteval); >>> - } else { >>> - dec_mm_counter(mm, mm_counter(&folio->page)); >>> - set_pte_at(mm, address, pvmw.pte, pteval); >>> - } >>> - >>> + dec_mm_counter(mm, mm_counter(&folio->page)); >>> + set_pte_at(mm, address, pvmw.pte, pteval); >>> } else if (pte_unused(pteval) && !userfaultfd_armed(vma)) { >>> /* >>> * The guest indicated that the page content is of no >>> -- >>> 2.30.2