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 964E2C54EBC for ; Thu, 12 Jan 2023 14:07:03 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C2CD08E0002; Thu, 12 Jan 2023 09:07:02 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id BDCDE8E0001; Thu, 12 Jan 2023 09:07:02 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id AA57B8E0002; Thu, 12 Jan 2023 09:07:02 -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 9BBB78E0001 for ; Thu, 12 Jan 2023 09:07:02 -0500 (EST) Received: from smtpin01.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 60F151A09C5 for ; Thu, 12 Jan 2023 14:07:02 +0000 (UTC) X-FDA: 80346323484.01.46C03C2 Received: from mail-wr1-f46.google.com (mail-wr1-f46.google.com [209.85.221.46]) by imf28.hostedemail.com (Postfix) with ESMTP id B6D00C001E for ; Thu, 12 Jan 2023 14:07:00 +0000 (UTC) Authentication-Results: imf28.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=MFX2NB5T; spf=pass (imf28.hostedemail.com: domain of jthoughton@google.com designates 209.85.221.46 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=1673532420; a=rsa-sha256; cv=none; b=IUTWS679hCOwYGKqpGwtjMYlElmGjgdUEfj8LWVY+dHE7ulQajGHmNNgRgHcjsKwJMjU+4 wz9nhFCd6Zc/MCRjLgKlcxd1/HfdKAD8CLslCQSgbSwq4Sbz7j2LUIV0y2DhXPJVi00UME H8X0GZwMdtqgiAsw3BOms/3dGoZm5x4= ARC-Authentication-Results: i=1; imf28.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=MFX2NB5T; spf=pass (imf28.hostedemail.com: domain of jthoughton@google.com designates 209.85.221.46 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=1673532420; 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=VeQspTnffiwI58L9LycVhK0E5SPBlYLIUK7B8t+8/6A=; b=H1XhbkxWtzP/40jhUrtd7W73BdGbiOSPNyRci3SFjylhsYy5obLK/JFETdsEezQ4ml4AQ9 +OreQK/AxOHUH+Wsal2ege2rnT1x7CC/IvtA3WN2+3J6+VXR51VbN609133IVXwBHkETIG pzbRZHFn2b7rCCtj71by/IMu7cFhsrU= Received: by mail-wr1-f46.google.com with SMTP id t5so13782066wrq.1 for ; Thu, 12 Jan 2023 06:07:00 -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=VeQspTnffiwI58L9LycVhK0E5SPBlYLIUK7B8t+8/6A=; b=MFX2NB5TMIFbOLH7I+9IQK889rOdZYfEhXxTxxThTb7W6cM+VdBHV99ld0Ek5raHWr 0QnGbZIaX/Uf3A7hezWUNwA5C+b1hltdMG7EfCPJQ99LDymNeyRB7MgnAU1usmV3lM0y BC7yCwUq3QusphxYA631uWFAVnnrsEHjVK4TbADR1U52gNzYeWEFQAx6hjabwqyHocE/ OKeATcA6Jc8tMpVpGkSp2kpiY8QGuu+PBNqBQCCpllEplmsQWbtqoXU4y/GizjSSJedC tW60ojiQS9r1lIjQbqQkoKN/uXhchTXy41RvYULJcTc07CYd75K6mhZl84pmq+rkcJs+ wdAg== 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=VeQspTnffiwI58L9LycVhK0E5SPBlYLIUK7B8t+8/6A=; b=Ju+ei/4U0D+xSTVbNKvV/hdF/6/6Bnj2oihGc9G3uJ9akhMmhWyWf9c5WtNwJeYlzm 8Mky/60KhziOQ3siAITob0rmoamekkA5hNaho7SBhEgLpp5pG9dsC+WXAE2Me7X3nKsG oVUdL7lbs9N1qZfRAozjXe8Bc9AGbmWyxaI6WLk4hoX2k73UsfiYDbcEtwU/gi3HZISF kKRRTRsdsHGzUmnTJ0QynF1r7nE/2xztEHkT6ZgIFxJnWY6tLRHSDHg6RK1tT00dzHrE VGgQ3T79PtVyDMd7+EdbcEgpFGRT3+c0q3WEWX5GRi+vvyDNIDwA7IOoIJ86m7tQcEG5 g21Q== X-Gm-Message-State: AFqh2koKCWZswDTh0L/0A6ye4aQji+QbUqzIxODmjr/937PXATTsRy1U xwKOcmaJQIQl/BXHHlmgDnA26N0dqt1oj3G1q93wag== X-Google-Smtp-Source: AMrXdXucJQn/K8isV2eY+/IdgIcNJyHlG81hYcnf/Bltvh3vgEDQRkW1xtnnHbhEt01DnGFPaMDQMysKTtjyleC3axk= X-Received: by 2002:a5d:6b51:0:b0:2b7:74c3:560d with SMTP id x17-20020a5d6b51000000b002b774c3560dmr1430049wrw.39.1673532419131; Thu, 12 Jan 2023 06:06:59 -0800 (PST) MIME-Version: 1.0 References: <20230105101844.1893104-1-jthoughton@google.com> <20230105101844.1893104-22-jthoughton@google.com> In-Reply-To: From: James Houghton Date: Thu, 12 Jan 2023 09:06:48 -0500 Message-ID: Subject: Re: [PATCH 21/46] hugetlb: use struct hugetlb_pte for walk_hugetlb_range To: Peter Xu Cc: Mike Kravetz , Muchun Song , David Hildenbrand , 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-Rspam-User: X-Rspamd-Queue-Id: B6D00C001E X-Rspamd-Server: rspam01 X-Stat-Signature: 899cwkhxyn4jr617hnmrf3ofh1187q66 X-HE-Tag: 1673532420-540117 X-HE-Meta: U2FsdGVkX1/C+kbRJ+YkLdk71D0SsvPjbGPgLu+eZS5BrAdjHS9oXC+kqRg+odRVsiI5ihF8dca3vSP92a50IFYQoPEkwMvXD1/OjCQfaq2cp37oR8YH3NuPI/6SfD0Um7qqBOAXsqHZUfRZIV9JHuiZbKKTO2uPEgDvQLi1qigBgxMaTe+CplrlgrtP/5gdR89HHyBb709t7BmQhX3vBAJcZ8Spkw4NL8lj/QptK5Bi3BgEEqc6e8qW7ZtN5BR1EJY/vLpEmuqMT1j83NWSvxkiPo9bsUdRXH0LEO9CEkeNpKTnTsgr3m3zwPNt4HJ62sLUdQyvB5cOjWogpqQwv7wE+fraRHmKeKqONiiFqF6jKy9utVAbhMqJdeEzyJVBc0GFV1dndXm3BH5lCjIHSCudobLMHfcC0G7efD7zuzAOC9d347Fh7HNZkQHf06jaKLZcA+GekOtg5FIBCKp/ByCwpbhvPvfOLUOISJJkUxXEUpWyWDALWprE0YbClQMW6dZ5ZwuGwqRKxjy5UWMHT4J7GT0Waxb45RRUNUEAiKaPM/McR+XX54qwT5RDv0NNobMPEUyvUlG9XOgxatwDtR//U+nhsIF0MFSS3iq774xjVjv3mRoBU+8meUXOsjGhwKZR/C7epjvIvZ0z5XSwrlkmA46fVg8gKCsC3/lAsr1/6SUEr0LsM8kQi1aQS5H48gHYBH+fTzYQRrXq2vicmLVRdl08Eh2Af03rXyodjbmvdveSZdHGuec9XLuQh293RaCDj8lrHaw4gSS+zELW9NBRdTgD57EZWJ90FRVY9kAiTeNcQH99sa5ElpWj+Ye8ffVBzjxRwRsqPl9c22ShrIt4HTfG6ccBTY5gSUP6Rj66arrpTQyAd9bzDUej5+RDYhE+Kj/DRZOpdnLnwPX1sueq8j02Q6B/Xng7pVJkAZdg9OC9m1KpdDzRlyJrS83UHQUi9veibTTVSzABhNM fPX1L6nx t9etJUqijKu2NwuFNWyZZo2tEADaovNzkOSwR5JPvDZ2oBZACZg6l3HDA0Q== 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 Wed, Jan 11, 2023 at 5:58 PM Peter Xu wrote: > > James, > > On Thu, Jan 05, 2023 at 10:18:19AM +0000, James Houghton wrote: > > @@ -751,9 +761,9 @@ static int smaps_hugetlb_range(pte_t *pte, unsigned long hmask, > > int mapcount = page_mapcount(page); > > > > if (mapcount >= 2) > > - mss->shared_hugetlb += huge_page_size(hstate_vma(vma)); > > + mss->shared_hugetlb += hugetlb_pte_size(hpte); > > else > > - mss->private_hugetlb += huge_page_size(hstate_vma(vma)); > > + mss->private_hugetlb += hugetlb_pte_size(hpte); > > } > > return 0; > > One thing interesting I found with hgm right now is mostly everything will > be counted as "shared" here, I think it's because mapcount is accounted > always to the huge page even if mapped in smaller sizes, so page_mapcount() > to a small page should be huge too because the head page mapcount should be > huge. I'm curious the reasons behind the mapcount decision. > > For example, would that risk overflow with head_compound_mapcount? One 1G > page mapping all 4K takes 0.25M counts, while the limit should be 2G for > atomic_t. Looks like it's possible. The original mapcount approach was "if the hstate-level PTE is present, increment the compound_mapcount by 1" (basically "if any of the hugepage is mapped, increment the compound_mapcount by 1"), but this was painful to implement, so I changed it to what it is now (each new PT mapping increments the compound_mapcount by 1). I think you're right, there is absolutely an overflow risk. :( I'm not sure what the best solution is. I could just go back to the old approach. Regarding when things are accounted in private_hugetlb vs. shared_hugetlb, HGM shouldn't change that, because it only applies to shared mappings (right now anyway). It seems like "private_hugetlb" can include cases where the page is shared but has only one mapping, in which case HGM will change it from "private" to "shared". > > Btw, are the small page* pointers still needed in the latest HGM design? > Is there code taking care of disabling of hugetlb vmemmap optimization for > HGM? Or maybe it's not needed anymore for the current design? The hugetlb vmemmap optimization can still be used with HGM, so there is no code to disable it. We don't need small page* pointers either, except for when we're dealing with mapping subpages, like in hugetlb_no_page. Everything else can handle the hugetlb page as a folio. I hope we can keep compatibility with the vmemmap optimization while solving the mapcount overflow risk. Thanks Peter. - James