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 38FD5C433EF for ; Thu, 30 Jun 2022 09:35:22 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 82FA96B0072; Thu, 30 Jun 2022 05:35:21 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 7B80A8E0003; Thu, 30 Jun 2022 05:35:21 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 632268E0002; Thu, 30 Jun 2022 05:35:21 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 4ED6F6B0072 for ; Thu, 30 Jun 2022 05:35:21 -0400 (EDT) Received: from smtpin12.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay12.hostedemail.com (Postfix) with ESMTP id 212AB121206 for ; Thu, 30 Jun 2022 09:35:21 +0000 (UTC) X-FDA: 79634394042.12.DF66203 Received: from mail-pj1-f51.google.com (mail-pj1-f51.google.com [209.85.216.51]) by imf26.hostedemail.com (Postfix) with ESMTP id 2D52214002B for ; Thu, 30 Jun 2022 09:35:19 +0000 (UTC) Received: by mail-pj1-f51.google.com with SMTP id b12-20020a17090a6acc00b001ec2b181c98so2357690pjm.4 for ; Thu, 30 Jun 2022 02:35:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bytedance-com.20210112.gappssmtp.com; s=20210112; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=rL6DMGGhflB32+5gUnVeD0pR8+KsqaqZLuRBQF3G2Qk=; b=VhbiN6QyzOQOkJswgUidFDK6rgIO8t1TbbGxo8RhSWrIlgiw94sKfZ7VHhRWHe7kA/ up/kzUI+aGzDT+fMJN4pYKiasBt3t/DhEym5ofBiVTpWGbpsWck6fgQMQKesrjPRHsta yL9TTe4GX6xuY0mQQTWABxl+gm8iTK42AlA8dQItHMauru98jQ4ipRnLQf0Toi8RE15J o7YuidgsIiK0UnZ0A09zsRuThzXo8qNqJVy1ndNDfpbDh43CuMDHERpStCTKI8L1DQ8g L+mdWBHA/D607l17RSiuztqOynugC0YErU74JeuP+KcBaG7BsyyBlwD1ug67r7/ETZDU t29Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=rL6DMGGhflB32+5gUnVeD0pR8+KsqaqZLuRBQF3G2Qk=; b=PcsLpz8c3y/hPSqtZtb/4yM8Oix+4mrxGf3yr/vFkG2uYPfOWBBgHcEZ2kg2xcZtH+ km4I4a4L+NT+R63GxMQWHdB2nRTWSEJvYIY+A04oo+UHfrBSj7gf9D8GjjHUepsItwmS +bS3Q6uFRYJg1Vupap4qW2r3uNSW0oP9eoyjnXQSHn7PATgLA+XSTW/LokcOOAV65pXZ 1hx13cGbjshN6wLyBNNl0qyjm9JqtzjNcU2gRK/33NG/rqoPeMwg8PRAEBfi38aB/By/ eH3uDJWa1Mk3purtVZDDpyHzHygzD6BQ1tm7E/C3nzknUp/5gJPLL1SGVGDUBsbrmFID 4izw== X-Gm-Message-State: AJIora92lr8dr2argteiDnt+5/UcCW7BUNFJDcYhE+v0v6i5Z9NDm8MG NK+AaJnV91/QQ3HRQ0OdlLHexQ== X-Google-Smtp-Source: AGRyM1upCGl6d90CWWZX08Fxj8CQnHyQl0xE9J+whD56/1jigDVzXVNjFr3eYykIwCabp+TWn5PvxA== X-Received: by 2002:a17:90b:4b48:b0:1ec:fc87:691c with SMTP id mi8-20020a17090b4b4800b001ecfc87691cmr11029817pjb.120.1656581718926; Thu, 30 Jun 2022 02:35:18 -0700 (PDT) Received: from localhost ([139.177.225.245]) by smtp.gmail.com with ESMTPSA id b14-20020a17090a550e00b001e31f4cc977sm3860054pji.56.2022.06.30.02.35.17 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 30 Jun 2022 02:35:18 -0700 (PDT) Date: Thu, 30 Jun 2022 17:35:14 +0800 From: Muchun Song To: Mike Kravetz Cc: James Houghton , 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 Subject: Re: [RFC PATCH 04/26] hugetlb: make huge_pte_lockptr take an explicit shift argument. Message-ID: References: <20220624173656.2033256-1-jthoughton@google.com> <20220624173656.2033256-5-jthoughton@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: ARC-Authentication-Results: i=1; imf26.hostedemail.com; dkim=pass header.d=bytedance-com.20210112.gappssmtp.com header.s=20210112 header.b=VhbiN6Qy; spf=pass (imf26.hostedemail.com: domain of songmuchun@bytedance.com designates 209.85.216.51 as permitted sender) smtp.mailfrom=songmuchun@bytedance.com; dmarc=pass (policy=none) header.from=bytedance.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1656581720; 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=rL6DMGGhflB32+5gUnVeD0pR8+KsqaqZLuRBQF3G2Qk=; b=dmQEW1wvCE5uAkRRm/3oCCivx2VKH4+lz1ElMESKDDy7ZsSfc76Sr6FxMGpqfG/FA+Dxzh yImcRIJAkZcmuZDHuvO/u0+ZiBXR4PwgKQfxVR6IvWujq/7iqw1pWXIaMBQtOkBWbBr09I rsejBT861cZRDx6TjW8t3t+LWKyrPa8= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1656581720; a=rsa-sha256; cv=none; b=dGI0mCjESKjXsi+HQ33+n0/hsnXi5h5bRAsdvTxENxVVFhLEhfNR9dNdosNq6WHd/R4u9y mgMHsCJ0RKx4A8kIFyBHzEKmHfkuk44VsPorWP6M5+ehxN3mn0qx8nUJ1xAqu4NPp9dTHA FNVBT/mQ8gle/PqdTkgQ4ynOP793kcQ= X-Stat-Signature: mpfasau456pbpbzd3b395uabangffks7 X-Rspamd-Queue-Id: 2D52214002B Authentication-Results: imf26.hostedemail.com; dkim=pass header.d=bytedance-com.20210112.gappssmtp.com header.s=20210112 header.b=VhbiN6Qy; spf=pass (imf26.hostedemail.com: domain of songmuchun@bytedance.com designates 209.85.216.51 as permitted sender) smtp.mailfrom=songmuchun@bytedance.com; dmarc=pass (policy=none) header.from=bytedance.com X-Rspamd-Server: rspam12 X-Rspam-User: X-HE-Tag: 1656581719-567831 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 03:24:45PM -0700, Mike Kravetz wrote: > On 06/29/22 14:39, James Houghton wrote: > > 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. > > I assume Muchun was talking about changing this in current code (before > your changes) where huge_page_size(h) can not be PAGE_SIZE. > Yes, that's what I meant. Thanks.