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 B851CC433FE for ; Thu, 17 Nov 2022 01:00:22 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E85C36B0074; Wed, 16 Nov 2022 20:00:21 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id E34E68E0001; Wed, 16 Nov 2022 20:00:21 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id CFD256B0078; Wed, 16 Nov 2022 20:00:21 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id C08E46B0074 for ; Wed, 16 Nov 2022 20:00:21 -0500 (EST) Received: from smtpin06.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 8EA80140ED9 for ; Thu, 17 Nov 2022 01:00:21 +0000 (UTC) X-FDA: 80141128242.06.0876461 Received: from mail-yb1-f173.google.com (mail-yb1-f173.google.com [209.85.219.173]) by imf25.hostedemail.com (Postfix) with ESMTP id 403E7A0009 for ; Thu, 17 Nov 2022 01:00:19 +0000 (UTC) Received: by mail-yb1-f173.google.com with SMTP id 205so163800ybe.7 for ; Wed, 16 Nov 2022 17:00:19 -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=C3URPOAvHtsPTjypQ/DqLBNZqOx50A4QEjRlhOOIhSg=; b=RITNO7Jc+hcF+RtMcmbs4vZSopP5WQfGrZor3dI2fXb07fA9DxGzSdrrggG8dRSVpg Nm+OE2pYYfnzjGhDM7ubOiF1iRrE9uiPmXaCBaoM59g1NglTvISfPJa0ThTDUxHL9jHv 4jyRJLxFGjg+YwN5RA1s72ieJp3NYq7KlYLQlGtbTiChr00lYQ+3sne2SVxuK2pBXzao UCdJes2xm6/ice4oGbPgrWrqkDWd7b/tnLVvIVPAS9LscInlFHVdannfeirMQ3KZ4HLp MPuw9EWvAE/+8nZpbokFdCn8WhzNa1TgKuzfY9UTXuSRr8hnj/IdG8MjBIDXt87fXsRB PljQ== 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=C3URPOAvHtsPTjypQ/DqLBNZqOx50A4QEjRlhOOIhSg=; b=JFgp8plz0xRILEKad2fkeYz6RZzcYbq4AYtI1ykCu12hzjllXYi8I2JMvDH7mrRGuy uh2AFKk//9gP4TZ8uH5WIqfr4R7EdIohLuLkoscJgoAnIN5wojXp9vXt+5Rjrb3dneXx wyMQb8lgA6uPBGIH0LSrZ/zOHGdGHitQWkvvjmGZFDAXzxrLlcSNBh6o7VNqvqsrQNJU HO+NFttK+IUKDMidzP6jAB2fzi+/EwAG+62xR6S0hygri6lf63+zPzghhVBLRDXkBHih ItWEsLIM38JzPCGg1smbly66YBX0p1MwBxoB871mKl0PA+AxrncXhEyI04ov8iVCe1FI 2Xkg== X-Gm-Message-State: ANoB5pmA3syR8jAYy57S+C0Uh+3EQ31VCzLLTn4IxVNUKIb9GnZlG6ud h3+ZUsa3JSIln8M0sBcJ4COCcagx4G/g4rFT2FDqew== X-Google-Smtp-Source: AA0mqf4PRbHhRy9BmGOMPBU7ZfK4XvohC9KRioTBz2t8jUra01nwI94HevlFrhRv1zZhfjy8hNABVnkQ9r0ik8xQx5w= X-Received: by 2002:a5b:505:0:b0:6cf:e605:7707 with SMTP id o5-20020a5b0505000000b006cfe6057707mr164264ybp.638.1668646819164; Wed, 16 Nov 2022 17:00:19 -0800 (PST) MIME-Version: 1.0 References: <20221021163703.3218176-1-jthoughton@google.com> <20221021163703.3218176-11-jthoughton@google.com> In-Reply-To: From: James Houghton Date: Wed, 16 Nov 2022 17:00:08 -0800 Message-ID: Subject: Re: [RFC PATCH v2 10/47] hugetlb: add hugetlb_pte to track HugeTLB page table entries 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" ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1668646820; a=rsa-sha256; cv=none; b=65LfVkHTplI9Hy0Xk75ZKiY/0Cgb7uSHKwjGctRDqIsAKtSpysSGfHyz9npTeBdE1PlVqh DM2DYU+wzUZOf2TeN12Lr8rq4uKRTak42sy1a9Y1QHvotc8bq6/inW5Xv1XU86MbjZbLKJ naFCjQEfPQkfgshxNKHJ1q+UueAy5T8= ARC-Authentication-Results: i=1; imf25.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=RITNO7Jc; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf25.hostedemail.com: domain of jthoughton@google.com designates 209.85.219.173 as permitted sender) smtp.mailfrom=jthoughton@google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1668646820; 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=C3URPOAvHtsPTjypQ/DqLBNZqOx50A4QEjRlhOOIhSg=; b=H1jCEIBDo5SM7cdMJgxpAN5pawAd9wRh0KIRHw7cqKhrk4mhx3IL24rEn/RBXxXC3JNreR lqIEdiCK6e/5Sta2Kvlo/D9IvMP5VIXaTzEjB/gEQTIY8jHGWVOo2PJKGrUJf+nbZrYz1B uXe9jD21PnUWV9cFPCX4JR1fW322bWY= X-Stat-Signature: 4fi7f71y5ouzc8j3mp6jnz3qc43mix18 X-Rspamd-Queue-Id: 403E7A0009 Authentication-Results: imf25.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=RITNO7Jc; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf25.hostedemail.com: domain of jthoughton@google.com designates 209.85.219.173 as permitted sender) smtp.mailfrom=jthoughton@google.com X-Rspam-User: X-Rspamd-Server: rspam12 X-HE-Tag: 1668646819-713625 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, Nov 16, 2022 at 2:18 PM Peter Xu wrote: > > On Fri, Oct 21, 2022 at 04:36:26PM +0000, James Houghton wrote: > > +struct hugetlb_pte { > > + pte_t *ptep; > > + unsigned int shift; > > + enum hugetlb_level level; > > + spinlock_t *ptl; > > +}; > > Do we need both shift + level? Maybe it's only meaningful for ARM where > the shift may not be directly calculcated from level? > > I'm wondering whether we can just maintain "shift" then we calculate > "level" realtime. It just reads a bit weird to have these two fields, also > a burden to most of the call sites where shift and level exactly match.. My main concern is interaction with folded levels. For example, if PUD_SIZE and PMD_SIZE are the same, we want to do something like this: pud = pud_offset(p4d, addr) pmd = pmd_offset(pud, addr) /* this is just pmd = (pmd_t *) pud */ pte = pte_offset(pmd, addr) and I think we should avoid quietly skipping the folded level, which could happen: pud = pud_offset(p4d, addr) /* Each time, we go back to pte_t *, so if we stored PUD_SHIFT here, it is impossible to know that `pud` came from `pud_offset` and not `pmd_offset`. We must assume the deeper level so that we don't get stuck in a loop. */ pte = pte_offset(pud, addr) /* pud is cast from (pud_t * -> pte_t * -> pmd_t *) */ Quietly dropping p*d_offset for folded levels is safe; it's just a cast that we're doing anyway. If you think this is fine, then I can remove `level`. It might also be that this is a non-issue and that there will never be a folded level underneath a hugepage level. We could also change `ptep` to a union eventually (to clean up "hugetlb casts everything to pte_t *" messiness), and having an explicit `level` as a tag for the union would be nice help. In the same way: I like having `level` explicitly so that we know for sure where `ptep` came from. I can try to reduce the burden at the callsite while keeping `level`: hpage_size_to_level() is really annoying to have everywhere. > > > + > > +static inline > > +void hugetlb_pte_populate(struct hugetlb_pte *hpte, pte_t *ptep, > > + unsigned int shift, enum hugetlb_level level) > > I'd think it's nicer to replace "populate" with something else, as populate > is definitely a meaningful word in vm world for "making something appear if > it wasn't". Maybe hugetlb_pte_setup()? > > Even one step back, on the naming of hugetlb_pte.. Sorry to comment on > namings especially on this one, I really don't like to do that normally.. > but here hugetlb_pte only walks the sub-page level of pgtables, meanwhile > it's not really a pte but an iterator. How about hugetlb_hgm_iter? "hgm" > tells that it only walks sub-level, and "iter" tells that it is an > iterator, being updated for each stepping downwards. > > Then hugetlb_pte_populate() can be hugetlb_hgm_iter_init(). > > Take these comments with a grain of salt, and it never hurts to wait for a > 2nd opinion before anything. I think this is a great idea. :) Thank you! I'll make this change for v1 unless someone has a better suggestion. > > > +{ > > + WARN_ON_ONCE(!ptep); > > + hpte->ptep = ptep; > > + hpte->shift = shift; > > + hpte->level = level; > > + hpte->ptl = NULL; > > +} > > + > > +static inline > > +unsigned long hugetlb_pte_size(const struct hugetlb_pte *hpte) > > +{ > > + WARN_ON_ONCE(!hpte->ptep); > > + return 1UL << hpte->shift; > > +} > > + > > +static inline > > +unsigned long hugetlb_pte_mask(const struct hugetlb_pte *hpte) > > +{ > > + WARN_ON_ONCE(!hpte->ptep); > > + return ~(hugetlb_pte_size(hpte) - 1); > > +} > > + > > +static inline > > +unsigned int hugetlb_pte_shift(const struct hugetlb_pte *hpte) > > +{ > > + WARN_ON_ONCE(!hpte->ptep); > > + return hpte->shift; > > +} > > + > > +static inline > > +enum hugetlb_level hugetlb_pte_level(const struct hugetlb_pte *hpte) > > +{ > > + WARN_ON_ONCE(!hpte->ptep); > > There're definitely a bunch of hpte->ptep WARN_ON_ONCE()s.. AFAIK the > hugetlb_pte* will be setup once with valid ptep and then it should always > be. I rem someone commented on these helpers look not useful, which I must > confess I had the same feeling. But besides that, I'd rather drop all > these WARN_ON_ONCE()s but only check it when init() the iterator/pte. The idea with these WARN_ON_ONCE()s is that it WARNs for the case that `hpte` was never populated/initialized, but I realize that we can't even rely on hpte->ptep == NULL. I'll remove the WARN_ON_ONCE()s, and I'll drop hugetlb_pte_shift and hugetlb_pte_level entirely. I'll keep the hugetlb_pte_{size,mask,copy,present_leaf} helpers as they are legitimately helpful. > > > + return hpte->level; > > +} > > + > > +static inline > > +void hugetlb_pte_copy(struct hugetlb_pte *dest, const struct hugetlb_pte *src) > > +{ > > + dest->ptep = src->ptep; > > + dest->shift = src->shift; > > + dest->level = src->level; > > + dest->ptl = src->ptl; > > +} > > + > > +bool hugetlb_pte_present_leaf(const struct hugetlb_pte *hpte, pte_t pte); > > + > > struct hugepage_subpool { > > spinlock_t lock; > > long count; > > @@ -1210,6 +1279,25 @@ static inline spinlock_t *huge_pte_lock(struct hstate *h, > > return ptl; > > } > > > > +static inline > > +spinlock_t *hugetlb_pte_lockptr(struct mm_struct *mm, struct hugetlb_pte *hpte) > > +{ > > + > > + BUG_ON(!hpte->ptep); > > Another BUG_ON(); better be dropped too. Can do. > > > + if (hpte->ptl) > > + return hpte->ptl; > > + return huge_pte_lockptr(hugetlb_pte_shift(hpte), mm, hpte->ptep); > > I'm curious whether we can always have hpte->ptl set for a valid > hugetlb_pte. I think that means we'll need to also init the ptl in the > init() fn of the iterator. Then it'll be clear on which lock to take for > each valid hugetlb_pte. I can work on this for v1. Right now it's not very good: for 4K PTEs, we manually set ->ptl while walking. I'll make it so that ->ptl is always populated so the code is easier to read. - James > > > +} > > -- > Peter Xu >