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 C5DBCC636D6 for ; Thu, 9 Feb 2023 20:22:45 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 14BA16B008A; Thu, 9 Feb 2023 15:22:45 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 0FAEB6B008C; Thu, 9 Feb 2023 15:22:45 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id EB61C6B0092; Thu, 9 Feb 2023 15:22:44 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id DB3AC6B008A for ; Thu, 9 Feb 2023 15:22:44 -0500 (EST) Received: from smtpin22.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 9E33280FB2 for ; Thu, 9 Feb 2023 20:22:44 +0000 (UTC) X-FDA: 80448876648.22.1C54C04 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by imf21.hostedemail.com (Postfix) with ESMTP id 46AC01C0002 for ; Thu, 9 Feb 2023 20:22:41 +0000 (UTC) Authentication-Results: imf21.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=fcbLRXqQ; spf=pass (imf21.hostedemail.com: domain of peterx@redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=peterx@redhat.com; dmarc=pass (policy=none) header.from=redhat.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1675974161; 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=22CmcsvPaM9XIPOOhNM72ZzlF0lYtjQ+dP35CSXhGrs=; b=dY/QTxYMkCCtx/7DTyFrjYttxE8QL8DSXo3oZ85sQ8jGY0vMJ60Jv1RsZ5AAka/UTlDf/1 P0blPxHexrKH2Dc4HgcfKDuVzNi8b5ezJJ+ycn5ip3ibowdJP00tm/AmGqt56Qo1i//5lC LXkqfK7qGk6SMgAIu3rpLmcjzj2ZEAA= ARC-Authentication-Results: i=1; imf21.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=fcbLRXqQ; spf=pass (imf21.hostedemail.com: domain of peterx@redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=peterx@redhat.com; dmarc=pass (policy=none) header.from=redhat.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1675974161; a=rsa-sha256; cv=none; b=CPZ1vjYoRL25jLdZLO8PQjgQr+FkqDetH9mrTNZYzhQsE9vE69zdkVa+kTtmurzB5w7+5b MtJI2J/pBYZ2JMMSNw7bauWJlhYhn2Gcjh9C2NnmMGtSLAQG9HKL2zZEXpmnfCs1whJ82a J8XsHlCrnXy4PXcfWH2YvDMt+W8yGHA= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1675974160; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=22CmcsvPaM9XIPOOhNM72ZzlF0lYtjQ+dP35CSXhGrs=; b=fcbLRXqQMuhCLwtnyxNC7szhg30f3M2ygjDiWu/cFHujEoKyzjuP3iANUlP9CNetxhJr+h W6fhsjURSB7r4N0IhqjTTFxVEcOnGP0i9enerJsoCStLgMQOGEmNh8EYiAdOz/Erm5Y72X EIBrmww1TydaZqxUNyl9EhyHVGjtUew= Received: from mail-qv1-f71.google.com (mail-qv1-f71.google.com [209.85.219.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-516-vMD20XqgMpa1_oMevpxQxQ-1; Thu, 09 Feb 2023 15:22:38 -0500 X-MC-Unique: vMD20XqgMpa1_oMevpxQxQ-1 Received: by mail-qv1-f71.google.com with SMTP id e5-20020a056214110500b0053547681552so1899481qvs.8 for ; Thu, 09 Feb 2023 12:22:38 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=22CmcsvPaM9XIPOOhNM72ZzlF0lYtjQ+dP35CSXhGrs=; b=g3NrDqm8mXReST7U/rQKcOJ6JWA3VWe7TId6wHfMx5cRrMG4dZwGBHceyEKpxpxqpi pVcR/F+OEGX+cp6eXZvauJR34Bbt1AD+WWkHy9H/7789qA26WO1e1cUGnCaiGj305pC2 q1dkf+YkYFuSRZMiVUvlc9B9hg0fFZJwobSZKLk1WDVGvOgKLUOYgqJjxJlxK0Wj2V9D HoLXAXGoY6Kb5tpBJ3mc67Z7iNgoiVnZbWxpeiVtq/GingmtGR9ccOPQAxHGgvpLGkwk i5wQAYAN6ciUZFta3gWKoCEmg/C1OHHUR0CS/qleQBs4n3lhoPf4Tr8Ll+E4Bxk9KRat xD0Q== X-Gm-Message-State: AO0yUKW3xbCRFG8Z6AsPm2pNbuRTh7hZne2AfQLwm98jvfceOegGvkzL mPKH8Yv51UCR7j+B+TJOgRMXqN70BbpSOJFxn/aUma4+V/9H1xHjlYdVaSUx+l25Kj7m0XnZw0o Z/PCy01ooMdY= X-Received: by 2002:ac8:4e8d:0:b0:3b8:5f47:aac2 with SMTP id 13-20020ac84e8d000000b003b85f47aac2mr25039855qtp.1.1675974157813; Thu, 09 Feb 2023 12:22:37 -0800 (PST) X-Google-Smtp-Source: AK7set/2S1j09igKbJogZdkwwYta3D17IevLtaU41oFt6c3NwTRE6ES6qGHcKfsd62Q2D8VqHMPmgg== X-Received: by 2002:ac8:4e8d:0:b0:3b8:5f47:aac2 with SMTP id 13-20020ac84e8d000000b003b85f47aac2mr25039815qtp.1.1675974157497; Thu, 09 Feb 2023 12:22:37 -0800 (PST) Received: from x1n (bras-base-aurron9127w-grc-56-70-30-145-63.dsl.bell.ca. [70.30.145.63]) by smtp.gmail.com with ESMTPSA id c26-20020ac84e1a000000b003a5c6ad428asm1828903qtw.92.2023.02.09.12.22.35 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 09 Feb 2023 12:22:36 -0800 (PST) Date: Thu, 9 Feb 2023 15:22:35 -0500 From: Peter Xu To: James Houghton 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 Subject: Re: [PATCH 21/46] hugetlb: use struct hugetlb_pte for walk_hugetlb_range Message-ID: References: MIME-Version: 1.0 In-Reply-To: X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Disposition: inline X-Rspamd-Queue-Id: 46AC01C0002 X-Stat-Signature: epb8wfagfrpooi3aetsq3npyg7bephkk X-Rspam-User: X-Rspamd-Server: rspam08 X-HE-Tag: 1675974161-290953 X-HE-Meta: U2FsdGVkX187CjxO96aQMaHr2DYYkRR5hJARNWHxZSSESMvTMuc9M/zhbI15GBgK5Jw62vtQArLB2uU+sNjlAMUQxxzU3P0DerkLKUdquDI2olYBj8rruVY8FW75AKP8LjtXybhmk7n/T7NIXLPe18J58RgXnpZHQN6zPooY+nOOKb0ss35TNbd08ww3lQRsf0X0LvABrjmbOI1Dvjg/rlC6yfsxGI0V2W8FCopNAGJ4qDXFVxt/gDMyCfTAX8LdpMIoB1W5zDV8peD6NibLF2NAHhB4O7Oo3lMmD7nKGRcCy9Kmo6or21RfjVu9rlmvvjF52lC5qv2RtmGE6aoO3YtJ/lQLK2Vrm87SNAH640Qff/cyVemez+Feuqhu8/6UktOGsfoT3goF0ZTnP/gBwQWKFFcg9nz4cvPGJX7sfWP4jYevDnAllAcuZG5yrABjM43mEapXwt7/vobw62kfAjIL+CuJC0BlMxcel6yU26R8Cb/QfxCRIWOLniAdwkaoMIwo1RQaKntG9BN4sbzjXVipSGBWGg2EYeeD2yHQyM9utQC+jfo6RGySb6p8ZztLxIqVJnx7kqtvTDF0Z9185vD63iqD49FpuHNekdHqYRoiiSJiqjeMZnq1S3lkrQ6/sZdBRwJFss00dLIKr1dG+5M1u5vR9wBREb4bZiv+/zLubDzKZl9Uki+DHsxbJEvKrpxHfp/x/m4DP/kbIc59ILuq7aqsXqu0lM0HJlc/Qt4+ren0UrRqg1gk3zE6pQn0553XQe3hrRfo0zcqKu72eBVqlw2jr0g69FWrnpx0WNv7XDLFwag/dGZxnctfB1jD9UGm1WXDbOtKzKED45SiFRDCHMPc94uvVbnZt/d5cyHjwHbqcQwEBsCRXvkdULlIB+EShg7kp30Z4K0GwQHmLsCCnG8Fe083aKIQMpSUGGOXiUWabHqZRRv1+aqTNFrDDQumJzeOe0ZpRSKl2KZ 5BNCPdmE NIrkkOtBY6iPNWMQ8zDsDN7pUm9Fd6ekOxw1wNbFqeqncAiSibDrP13nfyRrxzB1Sw9HKorzw+AIxF3kQ4QFe/2mMg9yfbNhuza8yiUY2W2fKRe+odrV5VVa3j/B9CVzTu3GmM7FoMzZL0dV272uz1/snvrDfoMpplnkYUsQ2sXJu3morP4UOMOh4HUb0RUA1/wsEAV2HLYlkcwp+zvqkVz/ELm/aEfXvqMXeI4SgVpFudkKeEKKaT1rBZ5J2+r1kbponT9BFXKFtEtw2wdDjC0NeR5RlSXI4HffQ1PE4CI0XyLSrLeC9wmw93X/L8WbRz8R/VNhQ+sBU0FpO5TBY8vAbnLrE9aEUBhuiUKKcvV54X7+McVajtbY6z0dObFSk7B+uQMn+sfWe0SQSoZcj6t3VAkQkPsL5aNwUwH+10QPR0iT6Ae/xhTWCTTUnHa+Y3Rhhj8/YH6pIFs1QxF/qZLcCBXMEj7PWBeE+ 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 09, 2023 at 11:49:25AM -0800, James Houghton wrote: > 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. Ah, okay. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 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. Yeah maybe flags are not needed at all. I had a quick glance, looks good in general. I think the trick is when it's not unmapped in a single shot. Consider someone zaps the first half of HGM-mapped hpage then the other half. The range may not always tell the whole story so rmap might be left over in some cases. But maybe it is not a big deal. The only thing I think of so far is the partial DONTNEED. but I think maybe it's fine to leave it there until another more serious request to either truncate or unmap it. At least all rmap walks should work as expected. > > I think something like [1] ought to go in its own series. :) > > [1]: https://github.com/48ca/linux/commit/de884eaaadf61b8dcfb1defd99bbf487667e46f4 Yes I agree it can be worked on top. -- Peter Xu