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 C59ADC43334 for ; Wed, 29 Jun 2022 21:39:34 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id DDA818E0001; Wed, 29 Jun 2022 17:39:33 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id D891F6B0072; Wed, 29 Jun 2022 17:39:33 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C787A8E0001; Wed, 29 Jun 2022 17:39:33 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id B8E046B0071 for ; Wed, 29 Jun 2022 17:39:33 -0400 (EDT) Received: from smtpin17.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay12.hostedemail.com (Postfix) with ESMTP id 7CF4F120650 for ; Wed, 29 Jun 2022 21:39:33 +0000 (UTC) X-FDA: 79632590226.17.2548C36 Received: from mail-pl1-f179.google.com (mail-pl1-f179.google.com [209.85.214.179]) by imf30.hostedemail.com (Postfix) with ESMTP id F334980037 for ; Wed, 29 Jun 2022 21:39:30 +0000 (UTC) Received: by mail-pl1-f179.google.com with SMTP id x20so9673940plx.6 for ; Wed, 29 Jun 2022 14:39:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=grTYKqu3D49Tj9S+6hVywvJcuRvZPDZs+w7+lCg6y2Y=; b=ZGiDA7Gk6s8v6m+wxsg4aJeGN49MHkVJ6CUt8p+6pvQ7nnJuWI4A/Q7ZXMyD8yKlKq 6GoAxnlBmld1YO5acfY1iXjl6JIIC73kAXosyHFPvtMSNfh3qFZaW4Oi4Xd7KxsLZIm0 f9uUYHVjHRSWcs3w6tow/EYfLb3sOOeASIJoUkgvuQ2X2qM3o8tn7mvuJ5NKO3hcCTEL wt32ym+p5Jbk0/xB7fFBsORwM8maLBIPLd1N0mF+Y2SX+THeM0HqjkroageyInNtyBp5 FrQJgf+N5qiYma9JZlKc7RpOX5qTo9fHkziFFi5HvFs5Va0liTNOksTdFnJ/HB2VMllt 6tVQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=grTYKqu3D49Tj9S+6hVywvJcuRvZPDZs+w7+lCg6y2Y=; b=39ok+skZAP8XyRw9RJtpO2dkJ6iU86S+tfbWnREmyS8whQsVAqsxPAlJjzTzA6V18C JR1yY2zSHlCqRYeOn+sieuATRKg3fkn16FcIAnxhdjHvSnKFCvxVO/DxTeFXZeD5ker+ F2SqBsdHcFgd87RN88QQLc7M7AomT4ixK5luVZ8s+3HCDJP0v4q/sMqDr8tTAU3JtCiW VrYJNG4T7QAoGa0Jx7iLsIvCoUI8ql9SaamoiIa94RqPCRi14TlmFRaa5MWD/UtIYjQ5 T/z3Kz9TEeh7pJWcHVKHC4fHRcLQv/5x5n9jZBuJJJw3FoGwdBS1w5lRPOYPAxpc+pcn hzwA== X-Gm-Message-State: AJIora/JfhZLaWHye/j7yavK6MYvQMXf0TGe8hQC0LsXBHlIWdVVDkjX Wo+aOphSIQQ3XxNESw7MMetY9mzWpDGVcihamwbUjg== X-Google-Smtp-Source: AGRyM1s1vwpEl6ikZ2qfTk1iog4Ag3ur80FKHxhmqAPsm+MrsXYjddvP90hD6D+5TEyFFkI0Qq9Fzl3gp+7KyqRZorY= X-Received: by 2002:a17:902:e94f:b0:16a:214e:46c1 with SMTP id b15-20020a170902e94f00b0016a214e46c1mr11095666pll.89.1656538769735; Wed, 29 Jun 2022 14:39:29 -0700 (PDT) MIME-Version: 1.0 References: <20220624173656.2033256-1-jthoughton@google.com> <20220624173656.2033256-5-jthoughton@google.com> In-Reply-To: From: James Houghton Date: Wed, 29 Jun 2022 14:39:19 -0700 Message-ID: Subject: Re: [RFC PATCH 04/26] hugetlb: make huge_pte_lockptr take an explicit shift argument. To: Mike Kravetz Cc: Muchun Song , Peter Xu , David Hildenbrand , David Rientjes , Axel Rasmussen , Mina Almasry , Jue Wang , Manish Mishra , "Dr . David Alan Gilbert" , linux-mm@kvack.org, linux-kernel@vger.kernel.org Content-Type: text/plain; charset="UTF-8" ARC-Authentication-Results: i=1; imf30.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=ZGiDA7Gk; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf30.hostedemail.com: domain of jthoughton@google.com designates 209.85.214.179 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=1656538771; 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=grTYKqu3D49Tj9S+6hVywvJcuRvZPDZs+w7+lCg6y2Y=; b=jAGmGZ9G3ZAMkSUK7XJWFbtuXESTytvA9rTELOjZepz6CR5rgWBWK/CzDY520lBHXI4kZ8 4Ocfvv9nSSqzqRPbRwdio9qA4QlqFZs8hRGmh265C0kYCJ39fLdY0sT6UPlDot+CaNP7I4 v5wWAGuSb42Fk+4qnIAeqlTQcN17zdw= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1656538771; a=rsa-sha256; cv=none; b=C6Lg+QPu5SZY8kk012ID2iY4tmvTI1OQKKeCKhwBKxcE2yJGJ09igMYkvD8V9dssthvakz oakZ04+IyCHGZPf8EAdR8WD8q7fEJXO0f8CJpw8vVv1LWgQIpv91H79VwtIMSRKN18OMW8 7qRHM6IP+X890kYnN99LeelMs/A6UfU= X-Stat-Signature: e784y44k9qszoi9n5o99idtj3hiha8ia X-Rspamd-Queue-Id: F334980037 X-Rspam-User: Authentication-Results: imf30.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=ZGiDA7Gk; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf30.hostedemail.com: domain of jthoughton@google.com designates 209.85.214.179 as permitted sender) smtp.mailfrom=jthoughton@google.com X-Rspamd-Server: rspam12 X-HE-Tag: 1656538770-780867 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, Jun 29, 2022 at 2:04 PM Mike Kravetz wrote: > > On 06/29/22 14:09, Muchun Song wrote: > > On Mon, Jun 27, 2022 at 01:51:53PM -0700, Mike Kravetz wrote: > > > On 06/24/22 17:36, James Houghton wrote: > > > > This is needed to handle PTL locking with high-granularity mapping. We > > > > won't always be using the PMD-level PTL even if we're using the 2M > > > > hugepage hstate. It's possible that we're dealing with 4K PTEs, in which > > > > case, we need to lock the PTL for the 4K PTE. > > > > > > I'm not really sure why this would be required. > > > Why not use the PMD level lock for 4K PTEs? Seems that would scale better > > > with less contention than using the more coarse mm lock. > > > > > > > Your words make me thing of another question unrelated to this patch. > > We __know__ that arm64 supports continues PTE HugeTLB. huge_pte_lockptr() > > did not consider this case, in this case, those HugeTLB pages are contended > > with mm lock. Seems we should optimize this case. Something like: > > > > diff --git a/include/linux/hugetlb.h b/include/linux/hugetlb.h > > index 0d790fa3f297..68a1e071bfc0 100644 > > --- a/include/linux/hugetlb.h > > +++ b/include/linux/hugetlb.h > > @@ -893,7 +893,7 @@ static inline gfp_t htlb_modify_alloc_mask(struct hstate *h, gfp_t gfp_mask) > > static inline spinlock_t *huge_pte_lockptr(struct hstate *h, > > struct mm_struct *mm, pte_t *pte) > > { > > - if (huge_page_size(h) == PMD_SIZE) > > + if (huge_page_size(h) <= PMD_SIZE) > > return pmd_lockptr(mm, (pmd_t *) pte); > > VM_BUG_ON(huge_page_size(h) == PAGE_SIZE); > > return &mm->page_table_lock; > > > > I did not check if elsewhere needs to be changed as well. Just a primary > > thought. I'm not sure if this works. If hugetlb_pte_size(hpte) is PAGE_SIZE, then `hpte.ptep` will be a pte_t, not a pmd_t -- I assume that breaks things. So I think, when doing a HugeTLB PT walk down to PAGE_SIZE, we need to separately keep track of the location of the PMD so that we can use it to get the PMD lock. > > That seems perfectly reasonable to me. > > Also unrelated, but using the pmd lock is REQUIRED for pmd sharing. The > mm lock is process specific and does not synchronize shared access. I > found that out the hard way. :) > > -- > Mike Kravetz