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 72913C636D3 for ; Thu, 9 Feb 2023 19:50:06 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id ED14B6B0080; Thu, 9 Feb 2023 14:50:05 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id E80D56B0081; Thu, 9 Feb 2023 14:50:05 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D48D96B0082; Thu, 9 Feb 2023 14:50:05 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id C27526B0080 for ; Thu, 9 Feb 2023 14:50:05 -0500 (EST) Received: from smtpin13.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 6C7771605CA for ; Thu, 9 Feb 2023 19:50:05 +0000 (UTC) X-FDA: 80448794370.13.B118CAE Received: from mail-vs1-f52.google.com (mail-vs1-f52.google.com [209.85.217.52]) by imf21.hostedemail.com (Postfix) with ESMTP id A49531C000A for ; Thu, 9 Feb 2023 19:50:03 +0000 (UTC) Authentication-Results: imf21.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=PzQDLW7Q; spf=pass (imf21.hostedemail.com: domain of jthoughton@google.com designates 209.85.217.52 as permitted sender) smtp.mailfrom=jthoughton@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1675972203; 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=olFywbvLrfXwhFHGfemOgr304ne0C352PmeiLfsF2Oc=; b=1cQC2EsCobAW//20aZ/OQW2/mn/+bOz8CP+i2xbgyOIulvZB4jTuXuwH7UvSPdcoCqnCOT 77HWDb/KZaENE4ibuWm33/0tIa6BSzGHJnSUfU+rVDY2Z+KSe/kpprAKUFDY3U1X3+7Vjh kvMKYnv/RkMc1V5x+FJA2tcPqFfKxiE= ARC-Authentication-Results: i=1; imf21.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=PzQDLW7Q; spf=pass (imf21.hostedemail.com: domain of jthoughton@google.com designates 209.85.217.52 as permitted sender) smtp.mailfrom=jthoughton@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1675972203; a=rsa-sha256; cv=none; b=EzC5mOLJlE1DD1jAIiEL43+vJyN/gVJDFq42gQtZHtw8zBBX6AHRES6MsYHsNZeajB9HU5 eQA5icu7yP9O8Md99uk9qoReKhPzXLrFTIdFyRFzgsESkyZy0Jj7lO1JYuj3oIAeP2wBdd 4dmUTCq+ZyV/zj0GaNI4HxXroYlNmF0= Received: by mail-vs1-f52.google.com with SMTP id p24so2492207vsn.12 for ; Thu, 09 Feb 2023 11:50:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=olFywbvLrfXwhFHGfemOgr304ne0C352PmeiLfsF2Oc=; b=PzQDLW7QIdPZwxSSyUuTRHLymbtwkkPN3Pq3+BRayY7EObWjO0E7MVxFCaU2ZH3u5k vEcAJoByu4akTjCfIfyTQlAOB65maUkAChOKM3hxduHbWBUmao9Tcuv5TICJXnSvviqz 9BbNoQlUyGp9bN+agkJijyA9GPtAnWO/TiObo+q/bpshutTK+LGZTDHD1iILr5c/Biu6 dQx+hovs7eS/Ulh2d3W7I/8x/GElQe19vRKM4u1b7ofhJLIlqXOiH3YKvsCg9ZE9icfq 4r0pVkKLo03ChI8LjKucq5e8tPM8POSCYInOlsZa9GW4hXuEGZ4dmDX59kvSslIl16Rb L43A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=olFywbvLrfXwhFHGfemOgr304ne0C352PmeiLfsF2Oc=; b=HFp2YE3oe606uvGWxiowByeI3c9hiKT92d7/r04k0qBEzH04h3936a9TsIc/OODvNi +7PDrBk94v3Mor699lNsWzSbG9BOKCi3c0mGc1ypmdZRxrsc0oeplyoFEWWI8sq6SkHz vm3jAxq+j+IIhzV4jjbfMGQTtquBYd1YuRQ0Rggs1+HEUPobwf7QoDWHT49MQdWcF0Ny G/PG7Fb4JMFkjPCBZ+YubounsvEjxYIOTAxC3z+EZrg0FXvV4MDud3IuzWsSk8vYk0jW UK5B+cyLHXnSfYMNBZPTns79QkMJ3qKh0YGNACzuUMk0qtgND73rO64I71WFfUUh6cN4 4IZw== X-Gm-Message-State: AO0yUKU5lxtCqC0bBtvy6h5eTPlpTrTTZ93dDgroxxvndpvPls0oN4Wq H6Mlzh4PKEUv9TNb80mxxw5yZMWGjOwBKfvfrtx/Kg== X-Google-Smtp-Source: AK7set8G/6ISFHb7vhOMOnRTtv3rW4MA87GnQYO4pEhykQbb7DjaZ7t8AbGOGTB/SO5x4X4fe0deeiznRkYANfftwBE= X-Received: by 2002:a05:6102:2e1:b0:411:c393:2def with SMTP id j1-20020a05610202e100b00411c3932defmr874047vsj.40.1675972202586; Thu, 09 Feb 2023 11:50:02 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: James Houghton Date: Thu, 9 Feb 2023 11:49:25 -0800 Message-ID: Subject: Re: [PATCH 21/46] hugetlb: use struct hugetlb_pte for walk_hugetlb_range To: Peter Xu Cc: Mike Kravetz , David Hildenbrand , Muchun Song , David Rientjes , Axel Rasmussen , Mina Almasry , "Zach O'Keefe" , Manish Mishra , Naoya Horiguchi , "Dr . David Alan Gilbert" , "Matthew Wilcox (Oracle)" , Vlastimil Babka , Baolin Wang , Miaohe Lin , Yang Shi , Andrew Morton , linux-mm@kvack.org, linux-kernel@vger.kernel.org Content-Type: text/plain; charset="UTF-8" X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: A49531C000A X-Stat-Signature: ub76whfdgdntmzkn1icc5bjd8xizkzjs X-Rspam-User: X-HE-Tag: 1675972203-113162 X-HE-Meta: U2FsdGVkX1/g4O3Gc32wyAdN9cruaHeYgiAK/ecBoyQsDDzdBhu6r4ubbmIL81ap1JO2qa9ujTRU8El4OKK3yhZdY0ruOUbULtp39how2LOx5YMEvTsSN21i/yihH+stdAAlN9NrBqCRdbqgFiuNCijAFdQf4UcYk5Ra1sm6mCWG4Znb2A2iMw+S61vGhMpdXcu9h/LJMYfO7bYCwfVgt+2dfu7audr8x30h/fXgqE+zjCKpSgOctt51x9OLG1LabkwZAO0bEtq+e47KBJeh26dM7IlTJeV9Pub0mXVlGQnVrAKbVScq4qz1UVl6cEi/LqqqjfzHMvAjmFafXnV1bpOiygs7LDHHxPOKDGu/FsTdgMqy/0NbmElRmlSqVlj+aWznPfjedHW4n7issNahpUVnfdLd21o3c+k3Ljx8ZVb3EPbphZzjCnIoBLnlmVQpt/FK7ZuxapBar7YtgKkUKoMQ/oJjOTBkUOr1Vo/pQZYlhF5HK7Kh2KGl0Oe2AKv9fLw+uwA7Y+xPBPUBdMWlFh0H0tfUKjKQQGqKC72nem2rlH1oP+MTLEQ5Dt+KYkN95U2lXQnQd37pWvIraJ56keqyOceN9Na2njJj4ObJtq2VJTb/OiN1ZAFOeATkLc5kPMqKFXC1w1+zTnAKQnlP5r3qKSB/19+0krRKl5IxPTcb0a8Q7+Q17/ovAhp+hlOMh9x5uIS1C22KO+uT7wrXRK4qqbK7kfkRQBIdlNGyAujJ4f8t3QNkDd8LXN3vtp4Edo0JsX/L84NQQDHrEs6Oj8YLPkoXPdS6cArCu2qnOSDvSRaVCFQjjHJ15WctFkN1rtej0rjB8DvMEu3hrpiB0FyN1aMLcUFWM81REjRyyIRYtaZtD4AkeVXsl+UawRTYJn9vBGIImXjW8n3Ae1+XsPXIrv1gKu6TpENXvL98s789U2qfqg9KSPjhz4OPsgGoP2s+0AUv1UqHbHPhC+9 9ZkLpsxx MmWCr4J2ukTQE5XbOJQvZI+lZ1jF3CJwFfKw6iWpiPmM715qrSmjmDydS39GRrgjunI2TlvOY5NKJcir8QFZu5AOgs3rYkSmGxgMieaA1RygdiCG4QkFcB4qD2wcqWDMJ4jolEBligf416WSm2p/3Go/olYtRNliulpJUTs42CR9/V5ofCKbrSxxMWN5M+iZGSbIUBQufj4d3WpLuAIvdzCTUCHnWtSX+cDQA4ifnSgNjh2eu7B49PdXroOU7FvvsRb+smecK6XBtM+LtIn5SfMiljI0wLAyPIisFVFdKXUEx9GhmXJysPe+xbepuwJ5ViSJf86H1K5LNVzsJfAwjiQSPdA== 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 Thu, Feb 9, 2023 at 11:11 AM Peter Xu wrote: > > On Thu, Feb 09, 2023 at 08:43:45AM -0800, James Houghton wrote: > > On Wed, Feb 8, 2023 at 8:16 AM Peter Xu wrote: > > > > > > On Tue, Feb 07, 2023 at 04:26:02PM -0800, James Houghton wrote: > > > > On Tue, Feb 7, 2023 at 3:13 PM Peter Xu wrote: > > > > > > > > > > James, > > > > > > > > > > On Tue, Feb 07, 2023 at 02:46:04PM -0800, James Houghton wrote: > > > > > > > Here is the result: [1] (sorry it took a little while heh). The > > > > > > > > > > Thanks. From what I can tell, that number shows that it'll be great we > > > > > start with your rfcv1 mapcount approach, which mimics what's proposed by > > > > > Matthew for generic folio. > > > > > > > > Do you think the RFC v1 way is better than doing the THP-like way > > > > *with the additional MMU notifier*? > > > > > > What's the additional MMU notifier you're referring? > > > > An MMU notifier that informs KVM that a collapse has happened without > > having to invalidate_range_start() and invalidate_range_end(), the one > > you're replying to lower down in the email. :) [ see below... ] > > Isn't that something that is needed no matter what mapcount approach we'll > go for? Did I miss something? It's not really needed for anything, but it could be an optimization for both approaches. However, for the subpage-mapcount approach, it would have a *huge* impact. That's what I mean. > > > > > > > > > > > > > > > > > > > > > > implementation of the "RFC v1" way is pretty horrible[2] (and this > > > > > > > > > > Any more information on why it's horrible? :) > > > > > > > > I figured the code would speak for itself, heh. It's quite complicated. > > > > > > > > I really didn't like: > > > > 1. The 'inc' business in copy_hugetlb_page_range. > > > > 2. How/where I call put_page()/folio_put() to keep the refcount and > > > > mapcount synced up. > > > > 3. Having to check the page cache in UFFDIO_CONTINUE. > > > > > > I think the complexity is one thing which I'm fine with so far. However > > > when I think again about the things behind that complexity, I noticed there > > > may be at least one flaw that may not be trivial to work around. > > > > > > It's about truncation. The problem is now we use the pgtable entry to > > > represent the mapcount, but the pgtable entry cannot be zapped easily, > > > unless vma unmapped or collapsed. > > > > > > It means e.g. truncate_inode_folio() may stop working for hugetlb (of > > > course, with page lock held). The mappings will be removed for real, but > > > not the mapcount for HGM anymore, because unmap_mapping_folio() only zaps > > > the pgtable leaves, not the ones that we used to account for mapcounts. > > > > > > So the kernel may see weird things, like mapcount>0 after > > > truncate_inode_folio() being finished completely. > > > > > > For HGM to do the right thing, we may want to also remove the non-leaf > > > entries when truncating or doing similar things like a rmap walk to drop > > > any mappings for a page/folio. Though that's not doable for now because > > > the locks that truncate_inode_folio() is weaker than what we need to free > > > the pgtable non-leaf entries - we'll need mmap write lock for that, the > > > same as when we unmap or collapse. > > > > > > Matthew's design doesn't have such issue if the ptes need to be populated, > > > because mapcount is still with the leaves; not the case for us here. > > > > > > If that's the case, _maybe_ we still need to start with the stupid but > > > working approach of subpage mapcounts. > > > > Good point. I can't immediately think of a solution. I would prefer to > > go with the subpage mapcount approach to simplify HGM for now; > > optimizing mapcount for HugeTLB can then be handled separately. If > > you're ok with this, I'll go ahead and send v2. > > I'm okay with it, but I suggest wait for at least another one day or two to > see whether Mike or others have any comments. Ok. :) > > > > > One way that might be possible: using the PAGE_SPECIAL bit on the > > hstate-level PTE to indicate if mapcount has been incremented or not > > (if the PTE is pointing to page tables). As far as I can tell, > > PAGE_SPECIAL doesn't carry any meaning for HugeTLB PTEs, but we would > > need to be careful with existing PTE examination code as to not > > misinterpret these PTEs. > > This is an interesting idea. :) Yes I don't see it being used at all in any > pgtable non-leaves. > > Then it's about how to let the zap code know when to remove the special > bit, hence the mapcount, because not all of them should. > > Maybe it can be passed over as a new zap_flags_t bit? Here[1] is one way it could be done (it doesn't work 100% correctly, it's just approximately what we could do). Basically we pass in the entire range that we are unmapping ("floor" and "ceil"), and if hugetlb_remove_rmap finds that we're doing the final removal of a page that we are entirely unmapping (i.e., floor <= addr & huge_page_mask(h)). Having a zap flag would probably work too. I think something like [1] ought to go in its own series. :) [1]: https://github.com/48ca/linux/commit/de884eaaadf61b8dcfb1defd99bbf487667e46f4 - James