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 A23A5EB64DA for ; Sat, 8 Jul 2023 04:02:21 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 194176B0071; Sat, 8 Jul 2023 00:02:21 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 11C0D6B0072; Sat, 8 Jul 2023 00:02:21 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id EFEB28D0001; Sat, 8 Jul 2023 00:02:20 -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 D9F9B6B0071 for ; Sat, 8 Jul 2023 00:02:20 -0400 (EDT) Received: from smtpin09.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 9430414017D for ; Sat, 8 Jul 2023 04:02:20 +0000 (UTC) X-FDA: 80987097240.09.B5F43BB Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf24.hostedemail.com (Postfix) with ESMTP id C165C180012 for ; Sat, 8 Jul 2023 04:02:17 +0000 (UTC) Authentication-Results: imf24.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=BtL71q5f; spf=none (imf24.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1688788938; 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=AfjkjixMYu2h2WslbSIJH5jv4hNa2iolRJaPXMMoIzc=; b=mngi7CyuGW4X8rX8H00TKIBydxgcN9ggQO7KRCu5x5mfCcEovCQ2Mojew5ojTyIwgJw0hI rC/lt1ocd9VPSh7+G9UxxGZSJqQqdNEdpKVLyIZgxKCTsGAEq0fTC75CTYD+gFIG9fpiN+ iIDJHl/NeCqWWsyB5DUM/scsElUUC+0= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1688788938; a=rsa-sha256; cv=none; b=QZ+7kxyUMCpj0ZblHwBC3WpBmh5/XzgNMIkIirajDXu7ZuKB1rDOkPNhf3t775NjhPCawY Ww3P0J03LsY1FzaUv3JQaYMyoZ23WuuZK/1ZFEC/D8lh8XC4wqEZ/4K3EDFgQElVoE2tpZ Rvg9JODS+wNPAJYVvhGeEz3blVP32UQ= ARC-Authentication-Results: i=1; imf24.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=BtL71q5f; spf=none (imf24.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org; dmarc=none DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=AfjkjixMYu2h2WslbSIJH5jv4hNa2iolRJaPXMMoIzc=; b=BtL71q5f+y7sP0xlZmxkwb84J1 yC2k81UmUmr1gqo36QiOVxQfPM//GIzSDMe1f9oNSUlgAi1B85kQ5HfH41uLSJlHciBBCqp5wwu0x 7ud0qMqJnImr5J9LE9BFmZAxGHXxExxRgykBf4hst3e/HpDxKdbw8wzT6HjE0JablLpRkDorwL6uY qTOg88Vrg7MjZ1Dg1GxVjUb1OvaIbHMlV6YKLXM8R0yb88c8ObODoBvDLiRR0vUOUx5QzXE2kVIS0 ScPoX9yA3YnPI1axeWWIpYveNNNCcjqt0EhbVonV2kTPWYgNKYj+gZV+H8hdXywKT9Ip/gJS7nf1l MTC2eBHA==; Received: from willy by casper.infradead.org with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1qHz97-00CcTy-Ki; Sat, 08 Jul 2023 04:02:09 +0000 Date: Sat, 8 Jul 2023 05:02:09 +0100 From: Matthew Wilcox To: "Yin, Fengwei" Cc: David Hildenbrand , linux-mm@kvack.org, linux-kernel@vger.kernel.org, yuzhao@google.com, ryan.roberts@arm.com, shy828301@gmail.com, akpm@linux-foundation.org Subject: Re: [RFC PATCH 0/3] support large folio for mlock Message-ID: References: <20230707165221.4076590-1-fengwei.yin@intel.com> <4bb39d6e-a324-0d85-7d44-8e8a37a1cfec@redhat.com> <436cd29f-44a6-7636-5015-377051942137@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <436cd29f-44a6-7636-5015-377051942137@intel.com> X-Stat-Signature: xm6oymke4c7u5whmqbnrw95jfa88izrc X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: C165C180012 X-Rspam-User: X-HE-Tag: 1688788937-803197 X-HE-Meta: U2FsdGVkX1/XAIGahAsMCjxgQ6xfcPsD3OmBh1AgSqNkMFRdebf2tvdrbd0dd02AFHbE595tLOH61B2O9NcVDwCp7pc3sRou111+MSWypyvm/4uCmux0YEHLxiL2tdR7hyp6NXqBXsk5ovxj09aCZ89DEjLrv7G9guCSeEgJxXAvveaDkyMaS/TEkJVgt7xT9FkBxE3JZkIi6Ge+7fP8LcmALBpWMWKzOQt8gbVEKlqUGIG635zOkD3ENSIXxL7So28N6/J1IFSjMdRMeMKymhoHo0RToRi6inG1a43uQYp4Aw/m4Jm7yg3PaONGggvb+YRwVwoawkGGq5uVh5IWbYP31ptCh6g/AIhDclCkDwVtRkt3ueHtWAiVGrpwFsRQbbBj2XPul1xrIjrh/V7rS2uDbjKd+mH8uTv9lvjigGbR3Xlt2HVQ8fPzs9eixtv+lalDLwegFxNeMWe4/ujvKSTudg3MZJLU2ekT55yZUZdE2zy3FY0RpHQe/m1/0w6RxwNCiV9XrT5t1kXlmQ4yW4uSablQlIyzLCxMG9yLuqgACWKZfwSCFtLG87/436uQForZczxsz5kuQzguq7V5X6qFIYqJ1wO41U3FFt6/ODgNs5hV4D6QtUZkSS/5gm1s/e/nUQOiJjmnVlmpdWpr/92xpZ8yCHjMkV3aTmN41ObtJ0Nw8MbJ0gwUasExCsAS1krXEhljWsWDDPKjHDrj1rQMONf1tahAPbEHu5+eLyw+5bMHHrwgs26YhbwcFzcNGs3B6p52M/DmMusi2MnmMMGaOTo51oNk1VjCA/GhvES2H9grX4BU23LJAEoAmcESFw4+I9+qrgtfgUSyajezhdWIAaa/0QfZiim9YuFVShMeZKgvxGHn288xXcMQc2MNMoYkTXSH6kFwyFxI4YZXucwNRaF6peTys/A2ifepAQrfqDHhFiKnPNnOHfKN4rpH/nWZWLBnWi8weUyzHgs fg6l5576 hZ4kNGCZgfyLE44USwvn2/kLseXB3AAlwlaLzqmB8ZBhX+1EQP8mYAnXhAmM53yZRVYFjblWTV3Tzs6CZmEi0g3qjD6NHN6flxbNhJQUXIFaAUWco9qLrL/PZpvVDlldMknikyEqp3Lb9Ih0= 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 Sat, Jul 08, 2023 at 11:52:23AM +0800, Yin, Fengwei wrote: > > Oh, I agree, there are always going to be circumstances where we realise > > we've made a bad decision and can't (easily) undo it. Unless we have a > > per-page pincount, and I Would Rather Not Do That. But we should _try_ > > to do that because it's the right model -- that's what I meant by "Tell > > me why I'm wrong"; what scenarios do we have where a user temporarilly > > mlocks (or mprotects or ...) a range of memory, but wants that memory > > to be aged in the LRU exactly the same way as the adjacent memory that > > wasn't mprotected? > for manpage of mlock(): > mlock(), mlock2(), and mlockall() lock part or all of the calling process's virtual address space into RAM, preventing that memory > from being paged to the swap area. > > So my understanding is it's OK to let the memory mlocked to be aged with > the adjacent memory which is not mlocked. Just make sure they are not > paged out to swap. Right, it doesn't break anything; it's just a similar problem to internal fragmentation. The pages of the folio which aren't mlocked will also be locked in RAM and never paged out. > One question for implementation detail: > If the large folio cross VMA boundary can not be split, how do we > deal with this case? Retry in syscall till it's split successfully? > Or return error (and what ERRORS should we choose) to user space? I would be tempted to allocate memory & copy to the new mlocked VMA. The old folio will go on the deferred_list and be split later, or its valid parts will be written to swap and then it can be freed.