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: 11744 Return-Path: Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:9f45:0:b0:3ea:f831:8777 with SMTP id v5csp3410529vqx; Fri, 7 Jul 2023 10:05:10 -0700 (PDT) X-Google-Smtp-Source: APBJJlFNZWz1p2M8m9d/1tSG+jsmNXTjx1um4m9O+a1da4Fv1pR8laUkoszZb83dCWf8gxkzvdbP X-Received: by 2002:a19:5045:0:b0:4f7:6453:f3f1 with SMTP id z5-20020a195045000000b004f76453f3f1mr4050088lfj.15.1688749510576; Fri, 07 Jul 2023 10:05:10 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1688749510; cv=none; d=google.com; s=arc-20160816; b=tz+f39PzIdzR4hdHf6WcfR/Ne4wSAFlQAgOtf/sNOsOk0k/1dcajqYQ6eEKhUPCkD8 /HX7cPTbfNXYR0/s0J1N7WLyMN7iIKx55Pule2nd/qlBue3rD1wl8UWAeKGOa542tsWg 6HBc98o/8iLVq951eBBEN+6YsvOFw4faJy2eetNNQtWIAm+borE5xveOw8jB0eVo1K7f AMwFMhSwXlgStEjVmkMB5LMCvfOwLu01QBh+LJzNavtfq84xbBoLksHwboCQHAqUAqNZ SJGkjA5hv83Z/7vjSb6sl/o14c8TLR60R7rdp5rXOjkBWIS2PgKfgMFDG8NHKFv/k7XP 9goQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from:dkim-signature; bh=5/vQ11zy2xsHJ3QBF/R2+rc2UgZHFuiFPLOcax9Q1FY=; fh=LCH763cqklLaGvVeU5MrvwAvEnSDPWcEneXIj6B58gE=; b=V6mCYpKCh/Nt+oks0R20cDa1KzPgebFsM8ASLxOx0X2/cfeqNdvyYMew5l4xd+chnv JntmB/6zLL7QTjAaPSNZzcSB2E9XjjEYyG7qHBZdrnu8XYJJKS2VOiGgDnWmIapW8n3O tKmgSD3N1BIiuTfT/HmqFrpn1gcVx8YPQmg8w8STAtQEd1YFQcqTwL8RoTLVvdbN/ICP yOABhs4TK9Rs42BobywR0s0BmNSI51F9cuWsGsOXlT5E1Z0K81TZV+u0QARPHFkCom0t TE1N7YhQHdwDcWWlTKoyld+/na9N9omXWko5dQ54EqADx45i/mtr7r3pO7K+EYfTxJwe s1KQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=kiaAsdAV; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id u6-20020a05640207c600b0051e19aae8d1si2424006edy.378.2023.07.07.10.04.46; Fri, 07 Jul 2023 10:05:10 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=kiaAsdAV; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232818AbjGGQxE (ORCPT + 99 others); Fri, 7 Jul 2023 12:53:04 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33348 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232467AbjGGQxA (ORCPT ); Fri, 7 Jul 2023 12:53:00 -0400 Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 9583C213F for ; Fri, 7 Jul 2023 09:52:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1688748751; x=1720284751; h=from:to:cc:subject:date:message-id:mime-version: content-transfer-encoding; bh=44TeDqOSGPdOaD7ZSx3H22uGfgMB+zSFFCjyv01ZsZU=; b=kiaAsdAVAevuvw6EoDUNk+RcnrgEJ2z84KFivzqdxq0VfNs4zQgxDaOx fTl8QsJ+wm9AzUwEA8k7XmSu2HcFxB2cvgKN3rHYhbgRKCyODsuT1yTGc /f59+3dHip33MxH8UD4Bifn4gnxwo7Upf21swhNt0QicObogcZrYZpmnN fFhNlR4FDj8YgXQ4kqxZ8g04dboL7VZSmVKzcw2CYXl7M/yPuxNzjEoLt 4fRtuQzmvfFFtJ82M5v+nlVYTeTZTvxVGRnDNrpOm/VVjKn0UPfoNAMi+ xyT9NwA3+ZMBYQcwJgrXXXmCA3himXMuSKimXwRJ7wgSIEYp8tpeLvXWE A==; X-IronPort-AV: E=McAfee;i="6600,9927,10764"; a="353776184" X-IronPort-AV: E=Sophos;i="6.01,189,1684825200"; d="scan'208";a="353776184" 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-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_MED, RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_NONE, T_SCC_BODY_TEXT_LINE,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1770782206755340530?= X-GMAIL-MSGID: =?utf-8?q?1770782206755340530?= 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(-)