From patchwork Fri Jul 7 16:52:18 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Yin Fengwei X-Patchwork-Id: 13305122 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 09AD7EB64D9 for ; Fri, 7 Jul 2023 16:52:28 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 4DA658D0001; Fri, 7 Jul 2023 12:52:27 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 489846B0074; Fri, 7 Jul 2023 12:52:27 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 351088D0001; Fri, 7 Jul 2023 12:52:27 -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 2563E6B0072 for ; Fri, 7 Jul 2023 12:52:27 -0400 (EDT) Received: from smtpin13.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 7453B809CC for ; Fri, 7 Jul 2023 16:52:26 +0000 (UTC) X-FDA: 80985409092.13.A4A02A3 Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by imf03.hostedemail.com (Postfix) with ESMTP id D27972001B for ; Fri, 7 Jul 2023 16:52:23 +0000 (UTC) Authentication-Results: imf03.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=JNdjM9o0; spf=pass (imf03.hostedemail.com: domain of fengwei.yin@intel.com designates 134.134.136.20 as permitted sender) smtp.mailfrom=fengwei.yin@intel.com; dmarc=pass (policy=none) header.from=intel.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1688748744; 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-transfer-encoding:content-transfer-encoding: in-reply-to:references:dkim-signature; bh=5/vQ11zy2xsHJ3QBF/R2+rc2UgZHFuiFPLOcax9Q1FY=; b=2VBh17O8O3lF4QKz09/GlsnU0TInE5WtRheTTx3Xzfeqc3irBwqg/hAZmuKfc/X7tmoqDW /k+x+PExRhx6GatpMLFUzxQ4Q3U2rLMbtWc9WrxffE6RvgwACD+lTx/dMvuatqwUpfUG+A AUd7L6HMzEiRaauvhd7S/NzKi8rZxl8= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1688748744; a=rsa-sha256; cv=none; b=vt0+OzcovKTrR8xbegGsYY0lNM6Vfi8oX7xHi1/Vw08NWF+Z33YgfhgTt+qBeFVssCR7od R6Z8fnBc6TdaKgOjKn6yb+QwpXNrbzHc9L8LYadtshKXv9bzBQwTiMwUPeEmmRbyEb8d48 dexNgi2plDGMysyBlDg1xdHOophgB5s= ARC-Authentication-Results: i=1; imf03.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=JNdjM9o0; spf=pass (imf03.hostedemail.com: domain of fengwei.yin@intel.com designates 134.134.136.20 as permitted sender) smtp.mailfrom=fengwei.yin@intel.com; dmarc=pass (policy=none) header.from=intel.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1688748743; x=1720284743; h=from:to:cc:subject:date:message-id:mime-version: content-transfer-encoding; bh=44TeDqOSGPdOaD7ZSx3H22uGfgMB+zSFFCjyv01ZsZU=; b=JNdjM9o0qlNna4MqVOZwknOAhc2PJVfp687pciR/aLzxX43nyn3Av8Dr dgBdD9RN0FW1EvrAo9KI6io/yn7WOBTvJno87+eTjCD/qGGhU8JBes5SN hKspsYwa2UD1iaVQOoEtz4zknwLMgutyyij0GzAmhVESp07V6o6o+KBi0 Pd1bSdknFakHnW/VddjFTVGwUnQWRT28T7bhYIX2ybL/IlsuXd7UlhjMd YFx9x6dxPz2KzG0vJzr1JE4yirWYIH/WN/Y6PDOss5fJbQ0TaqscP5DiQ xwAPVKhxLmhUWAAm5jVDv980uiKomCxLgFa3upUwkqyiRJYHat8RtVcAs g==; X-IronPort-AV: E=McAfee;i="6600,9927,10764"; a="353776186" X-IronPort-AV: E=Sophos;i="6.01,189,1684825200"; d="scan'208";a="353776186" Received: from orsmga006.jf.intel.com ([10.7.209.51]) by orsmga101.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 07 Jul 2023 09:52:22 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10764"; a="697290400" X-IronPort-AV: E=Sophos;i="6.01,189,1684825200"; d="scan'208";a="697290400" Received: from fyin-dev.sh.intel.com ([10.239.159.32]) by orsmga006.jf.intel.com with ESMTP; 07 Jul 2023 09:52:19 -0700 From: Yin Fengwei To: linux-mm@kvack.org, linux-kernel@vger.kernel.org, yuzhao@google.com, ryan.roberts@arm.com, shy828301@gmail.com, akpm@linux-foundation.org, willy@infradead.org, david@redhat.com Cc: fengwei.yin@intel.com Subject: [RFC PATCH 0/3] support large folio for mlock Date: Sat, 8 Jul 2023 00:52:18 +0800 Message-Id: <20230707165221.4076590-1-fengwei.yin@intel.com> X-Mailer: git-send-email 2.39.2 MIME-Version: 1.0 X-Rspamd-Queue-Id: D27972001B X-Rspam-User: X-Stat-Signature: zodoyrc7m754jer5qoe7aes8f7xrem8o X-Rspamd-Server: rspam03 X-HE-Tag: 1688748743-728260 X-HE-Meta: U2FsdGVkX1/pOb/q/n1fdOjyjb3neD2v9u9+3epYn8jxHpsvAljj8y2dy6xr5wNfCfIY3dtiki5RuX2kZzbOdG2bagnvHEifqA/NlAnK54vyuTJ/47U+CdOASB0WESEi3Ao/u1pJpnXVzFU6JPUyEM55HYuO2UyxI1pl9RFv9WfxwDieitKFrRjBx+ejGaZSD5bYQ3iiJHQgQqfHCywEYrB0nYvi+OxlUsRqxGAmy86SSlqeadfJ778OUiMsikc2yH+yHaBWSPGjVoSXZOmLYeNNlm/y1FpCQpgLsrUv9gy8SUEZGfcqJ1lGBRgaVqE8j9Sr2fJOmXYVuYL3XzDCBesqztgtWhobQps2AUSxGgqDApUY2hKc1idzCQKCZHnJohnLncymFsf2GzqA23+uWN59uBrSUCBYc5nDXe1s2Anb4emUqLh6QYw+L0Tt6eoD3L7CsyOa6xa7GsmgmnMH1H8SAfCOwTkimr/w+OLFfRl6G+fP19hUrxwUQOeLtsugzcRXaSclEw3OiJwHPEjJiD/YSLea0fzE/i5Trr4RoVDvgBZHS4f+p5ffUo09G72XHycU8KMcr8ol805v0BIeZnI7HiKcR/naee1UUnrbsG3js2csuiWnZHBreJGjo+gsv1nlQf9amj39yGNbnqnZyDjxxQZSTE/DQzwry1Ax+qeKzh/6eJRW3JqLskspmbqWUO1jZ+vG/xMaXvzWefabPENi1m/wdVZbomKhakciXdrDCF8zotdfGtbYhA863kCnDwRDRlUnjly2mEaej3w+Y9OM6wuJkYhoWcft9uxshQ2OGq8Xuq/WgRoX4OgNNYFdWBAPpENPgQFmGJnQXmmVMEV33EBVlsCQ5K86i9lXhuajJ4CDv9Q71XN4vfR1S0eJlsbFTGYO2WgF7RAw6aeOJQXHkXoq//RsnubW1HcbmNVrKPTn27j1wysag6gFotMboTvGiSZtWZ15X2KbHHE eGNrnBAa mhUHIapPvgQ4Os34HixwfWfBhfTowWyS5G4Zjgc8KNyZZlG9mOCdiUXlW1K+Hms9KTCRv3kz46iA2W+7ex7Yokp0wP2J1RbVXXAKit8ww5x5KmodVEqux0wAznRPMSBCax4tuJtkFEB4S9It+vj62EVqu7iAXg9hAeL39/2rpefgxoog5yi9t8YV3ZLqONn09IS87Jx3acUnXBD05X38YTe5nvw== 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: Yu mentioned at [1] about the mlock() can't be applied to large folio. I leant the related code and here is my understanding: - For RLIMIT_MEMLOCK related, there is no problem. Becuase the RLIMIT_MEMLOCK statistics is not related underneath page. That means underneath page mlock or munlock doesn't impact the RLIMIT_MEMLOCK statistics collection which is always correct. - For keeping the page in RAM, there is no problem either. At least, during try_to_unmap_one(), once detect the VMA has VM_LOCKED bit set in vm_flags, the folio will be kept whatever the folio is mlocked or not. So the function of mlock for large folio works. But it's not optimized because the page reclaim needs scan these large folio and may split them. This series identified the large folio for mlock to two types: - The large folio is in VM_LOCKED VMA range - The large folio cross VM_LOCKED VMA boundary For the first type, we mlock large folio so page relcaim will skip it. For the second type, we don't mlock large folio. It's allowed to be picked by page reclaim and be split. So the pages not in VM_LOCKED VMA range are allowed to be reclaimed/released. patch1 introduce API to check whether large folio is in VMA range. patch2 make page reclaim/mlock_vma_folio/munlock_vma_folio support large folio mlock/munlock. patch3 make mlock/munlock syscall support large folio. testing done: - kernel selftest. No extra failure introduced [1] https://lore.kernel.org/linux-mm/CAOUHufbtNPkdktjt_5qM45GegVO-rCFOMkSh0HQminQ12zsV8Q@mail.gmail.com/ Yin Fengwei (3): mm: add function folio_in_range() mm: handle large folio when large folio in VM_LOCKED VMA range mm: mlock: update mlock_pte_range to handle large folio mm/internal.h | 37 ++++++++++++++++-- mm/mlock.c | 103 ++++++++++++++++++++++++++++++++++++++++++++++---- mm/rmap.c | 3 +- 3 files changed, 131 insertions(+), 12 deletions(-)