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 4F614C05027 for ; Wed, 1 Feb 2023 18:01:51 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A8FD36B0072; Wed, 1 Feb 2023 13:01:50 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id A18C66B0073; Wed, 1 Feb 2023 13:01:50 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 86ACC6B0074; Wed, 1 Feb 2023 13:01:50 -0500 (EST) 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 7167F6B0072 for ; Wed, 1 Feb 2023 13:01:50 -0500 (EST) Received: from smtpin21.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 33C7680CE8 for ; Wed, 1 Feb 2023 18:01:49 +0000 (UTC) X-FDA: 80419491138.21.D0DB617 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by imf15.hostedemail.com (Postfix) with ESMTP id 1041AA0031 for ; Wed, 1 Feb 2023 18:01:39 +0000 (UTC) Authentication-Results: imf15.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=idVWI7kv; spf=pass (imf15.hostedemail.com: domain of david@redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=david@redhat.com; dmarc=pass (policy=none) header.from=redhat.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1675274500; a=rsa-sha256; cv=none; b=i1E+BGNQyRWEU+UvcF7hZfiBg1tXxQh6gTX0jKz2VukyvnDMMZo16RkHwaUH/g+4I6GsE0 pegQmAvaMuMrWYUT9w2OMBmn1DdJu6fIe0ciHltFI6kZFcllpEsH9p+EJia7fuQg7PoGRf iNDf57XkZAMdTRwInFcBaSDL5sdTW9E= ARC-Authentication-Results: i=1; imf15.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=idVWI7kv; spf=pass (imf15.hostedemail.com: domain of david@redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=david@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=1675274500; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=VzqzAAb573Rx+S9XOi2MvYGh3YMO5S6xiAho5p3UfWw=; b=BIZVQXoec1Z/nrtPA4WRA/HX10Y/ctuAt/p8Waf2tLNwrkNrq77clWGCs8R08YKtEfotZi M3T4dxnJjb4zF9rZK/+SvnOEfzY5NavdHWr+sM1h1USdOfKL9Btb+rKEQ9E8fOStNGndoY jujnwOzm7+HC3eKltLfChYctgjmr5oU= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1675274499; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=VzqzAAb573Rx+S9XOi2MvYGh3YMO5S6xiAho5p3UfWw=; b=idVWI7kv5gF/cSHOptjd9NCYrX9k2HuVxTNRvr7qvoCTk+jJoUzD0B0GyDAMSALEePF2e5 +ShdiwhgeBpFhJO+U4/QlQXBLFxxCs+cocMq1MW5WcX9YPiMg2NmdrDwSA8pM2EhOQNlJf Ni/6vQCp4+gSlrdNoiOhFr+6E0valcg= Received: from mail-wm1-f72.google.com (mail-wm1-f72.google.com [209.85.128.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-581-2Lf45j33MnC0uR0WcB_vpg-1; Wed, 01 Feb 2023 13:01:36 -0500 X-MC-Unique: 2Lf45j33MnC0uR0WcB_vpg-1 Received: by mail-wm1-f72.google.com with SMTP id j37-20020a05600c1c2500b003deaf780ab6so1218459wms.4 for ; Wed, 01 Feb 2023 10:01:35 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:organization:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=VzqzAAb573Rx+S9XOi2MvYGh3YMO5S6xiAho5p3UfWw=; b=nzARtAICJplCXuZHhqV00KPU3Yj7yae/lF7P3uE2eOmtSh3+x/tqlog+HbxNhFYP+V wiCQAl64E2Ig1czObhsFykXmAWt8kD12sVdKbb3HfUACKJ6DYR6dxLItEMoU3SeeQPzF a9kiUDby7BCaSEg0wCeCkL+zSPXTSD0RQyPQWliFZOYXw5YDPkLG6zzgNPM6xVYPn9Ui V7n5KSav7QEQj2jp/sn1+gq21VA6IjuCXyPnOqRNE+Rb95gb7x1daznYDLQPeb4RhI5h I94hQYJftF7EFk+AKTqWNOKWlSgt5VGo5Rp053fQAzgq99BijZfK6a6dPoEbucURZByv IWXw== X-Gm-Message-State: AO0yUKW/2G5S8Ak6qOn51rSrXz+sfNkwROmijkypjtkliIDu94csmJVD GbEUtsPcDDwLTukF6AE5rdTP8w2T9albagWdmeVvXxVTZXQc/AvsNEE6HB9MUWcJtuAd9lyC4Cu CeWgcxmCn2ns= X-Received: by 2002:a05:600c:3ba3:b0:3dc:58a2:3900 with SMTP id n35-20020a05600c3ba300b003dc58a23900mr2913434wms.29.1675274495066; Wed, 01 Feb 2023 10:01:35 -0800 (PST) X-Google-Smtp-Source: AK7set+/xHGDYtC/e/DSVq6MtlcqpQluPH2ueNrUdpbpHeoXKUweiE6CqyCelXmWCRF0Sy/EvM8qUA== X-Received: by 2002:a05:600c:3ba3:b0:3dc:58a2:3900 with SMTP id n35-20020a05600c3ba300b003dc58a23900mr2913404wms.29.1675274494825; Wed, 01 Feb 2023 10:01:34 -0800 (PST) Received: from [192.168.3.108] (p5b0c6231.dip0.t-ipconnect.de. [91.12.98.49]) by smtp.gmail.com with ESMTPSA id p35-20020a05600c1da300b003db16770bc5sm2524684wms.6.2023.02.01.10.01.33 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 01 Feb 2023 10:01:34 -0800 (PST) Message-ID: Date: Wed, 1 Feb 2023 19:01:32 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.6.0 Subject: Re: [PATCH 21/46] hugetlb: use struct hugetlb_pte for walk_hugetlb_range To: James Houghton Cc: Peter Xu , Mike Kravetz , 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 References: <7a1bc3c5-6efe-87ab-1276-f71fc440c821@redhat.com> From: David Hildenbrand Organization: Red Hat In-Reply-To: X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspam-User: X-Rspamd-Queue-Id: 1041AA0031 X-Rspamd-Server: rspam01 X-Stat-Signature: kpc1d5tok7qp5pcxyc8w67ek8h9i34wz X-HE-Tag: 1675274499-762884 X-HE-Meta: U2FsdGVkX19TBr3W+PJm8+PJ1EkubZxVxakFioVBxsNH/ATZdZE3MxBjZo9cHWi5Tbp0Txty0m1gKOp7wAuY7281Gm8XoMjMtx9sfwyFdUZ1Ongb9QcZOmjodvQYtQJouwLvAV4PSIzrfuqMHBRw3E1JFn2K+L1XR8cdXHhOP5HQ8AbjEvvb2meviwp6XmdbLecoI20aE+hUSX8AMeZd5PquJ200Ne1nGs/2j1UkW6gomZDl6pcNcyyRfJKscmAvi9t2mPJFkAsWs96m7JlPYoFkOG7s8SO5Y2z0zWqoUvLdmrRdbv/0/JBJE2AH8HdV16BfbgatLcpOHK+JdEsNlRkgqPzSiQSoMPD2nrM7COfAzB17JGqPSNqGPPxOGCalCsqJkONJ6/7QjVxRKaSU/7a2pOwjmcMgTe0IacoDuWiek2Qyy7ruhnIKC41NEEYwfp7UNxf0Kxgg00ciIsuJK539st16+TKsfdfz10xmlQ3RLe3/WTTMLLmmcJGSxAHu8PEKJ5iSh73IQ9ABGqWvpnvnWBOUBJV1+kyXXQhcjVVbSIXA4jzA4CpeTPMh025YJBZ5R57XNO0UQ+KH2oK6pIWX3CfIZWTmUA1RC0NH/d3mICvHGynz5RvDk2EFluHj/seutd1ZilZnSoE+QQqrhMQ6FMQJFaJ+kPyDbHagKwAIkqcETCzYmVIVQ5yIR9aJCjTWlQIzfp8UJtVgyK3evK+ezvF55DUZDEBNVvJn4gS3f2jqAVRjGWMakhbi5gDMVkVu5B8W4SsuZcHryJURfw4uSx70knfMJ8RfbiZgewseX26nPWkgbdQXRX+kdeg0GHeNn2g57aRs2ig23ZSqMj7+lnBguEoAZIVG0GBf+Ao8fejJJPt8ym3NRyhXaK0gqbmPpk6HuONGs0IPeg3sP6uda+lII1Wu+1PDFjOYyz9Ck/OxkiZjTQQZPAaSITHfFIT0QVXwtrT2U+njtdh jnm4ENzf 9jFm/Q2pXVHhOlj4A3E81dYgbt0PScwZhZo7H2O40WAulndQDqBedyrpE9jtIzlIwPSH8PhFSM+3RFJUfZxNB0FAjgAxs+bEGcuPM1ATWbuZNsPMMaQ3zCxE7fUZKTDjbl2HIcCDar5DWM3mVi7zOTmQsnH21pPcPSSV26/Oe2ygWfFd7tqeEg9Ppd5N6bFBcjCxlbFTPyWLqgJhNE4gUEnz61pj0DrDjsGuR+2/1+Ov+ezmSpD4Yb7ZySv3u67eLuQ1p1xmOguTNePltOsMIVGZvEE3SCQrXlhFdg0Rk/fk3vXZ8OlTiOfC4x7AlJwnMP7vBvtEYi/4KKq5jJdAHMWKLAB/mAnTSEwRZwX9NXUpWV8TltcgYvAjSGw== 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: >>> 1. The RFC v2 way, which is head-only, and we increment the compound >>> mapcount for each PT mapping we have. So a PTE-mapped 2M page, >>> compound_mapcount=512, subpage->_mapcount=0 (ignoring the -1 bias). >>> 2. The THP-like way. If we are fully mapping the hugetlb page with the >>> hstate-level PTE, we increment the compound mapcount, otherwise we >>> increment subpage->_mapcount. >>> 3. The RFC v1 way (the way you have suggested above), which is >>> head-only, and we increment the compound mapcount if the hstate-level >>> PTE is made present. >>> >>> With #1 and #2, there is no concern with folio_mapcount(). But with >>> #3, folio_mapcount() for a PTE-mapped 2M page mapped in a single VMA >>> would yield 1 instead of 512 (right?). That's what I mean. >> >> My 2 cents: >> >> The mapcount is primarily used (in hugetlb context) to >> >> (a) Detect if a page might be shared. mapcount > 1 implies that two >> independent page table hierarchies are mapping the page. We care about >> mapcount == 1 vs. mapcount != 1. >> >> (b) Detect if unmapping was sucessfull. We care about mapcount == 0 vs. >> mapcount != 0. >> >> For hugetlb, I don't see why we should care about the subpage mapcount >> at all. > > Agreed -- it shouldn't really matter all that much. > >> >> For (a) it's even good to count "somehow mapped into a single page table >> structure" as "mapcount == 1" For (b), we don't care as long as "still >> mapped" implies "mapcount != 0". > > Thanks for your thoughts, David. So it sounds like you're still > squarely in the #3 camp. :) Well, yes. As long as we can get it implemented in a clean way ... :) -- Thanks, David / dhildenb