Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Thu, 30 Jun 2022 10:40:47 -0700
From:   Mike Kravetz <mike.kravetz@oracle.com>
To:     James Houghton <jthoughton@google.com>
Cc:     Muchun Song <songmuchun@bytedance.com>,
        Peter Xu <peterx@redhat.com>,
        David Hildenbrand <david@redhat.com>,
        David Rientjes <rientjes@google.com>,
        Axel Rasmussen <axelrasmussen@google.com>,
        Mina Almasry <almasrymina@google.com>,
        Jue Wang <juew@google.com>,
        Manish Mishra <manish.mishra@nutanix.com>,
        "Dr . David Alan Gilbert" <dgilbert@redhat.com>,
        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: <Yr3gH6F3R5lSwcWf@monkey>
References: <20220624173656.2033256-1-jthoughton@google.com>
 <20220624173656.2033256-5-jthoughton@google.com>
 <YroYaWVvNZJvtqsH@monkey>
 <Yrvsn66c+UI8ZQlO@FVFYT0MHHV2J.usts.net>
 <Yry+PPHSat2uN+aG@monkey>
 <CADrL8HX9OkuWzpODBzHx-6-7_SLJ1YCCe5HxXdPa4ibqeQZu3A@mail.gmail.com>
 <YrzRLVQaYtYAYsEa@monkey>
 <Yr1uUmfA/iWO740v@FVFYT0MHHV2J.usts.net>
 <CADrL8HWuF-yXvgdJW7wWQSMU0GsRg3gttHykhV7=1VYSxfzkag@mail.gmail.com>
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CADrL8HWuF-yXvgdJW7wWQSMU0GsRg3gttHykhV7=1VYSxfzkag@mail.gmail.com>
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?7xqYMrev1HEoxXe4QhXGtUV7Cz1/kzuUPux0EHBi6V3+wvRUI6DPVjVJRp+i?=
 =?us-ascii?Q?iGKY8iT8PnHX39hiwCrMCUbbTHSVe9m0E7Hb2wZbsIz5BIc0QSzuqAky+wxm?=
 =?us-ascii?Q?B0O+Jg2IC42031fGPd9OH8plj9yXxEZYY2zApge4zh3zFkYyZnYw8mrPqE12?=
 =?us-ascii?Q?TDneDu8xIQo5QtqkylpGLIu5APVt9PAnS4Wwp6LKHzO0cXIspVQ+CzuZk1D+?=
 =?us-ascii?Q?FpYnR82XGMNfxTbg2qT1cMfoR4x4NV+jKxglDfkS4pCHlpUTUd1KdJiZhJnf?=
 =?us-ascii?Q?ijr8CfZWNOI2UY8x3lSc/8a5G71JLm2vKwrJXqX75euXntATCbgimlguvYhc?=
 =?us-ascii?Q?DqMl0JlJ2zfv4G/fVIQT8eZLCkwpNUBpHCpRSq8g81+TQPOlZZOvBtcd8910?=
 =?us-ascii?Q?ByyHG/pDYr/bi9kkoYPfugNU6WdBj4VLISbxBJrU2Wr9qT+fj4i9Of3OR85m?=
 =?us-ascii?Q?KGsvfrNqeed8tFvLuGEgRe9sdF8vhIuSxgK9FJahbfH7l+5s8lxnqnnw1v+B?=
 =?us-ascii?Q?oCOEpp3Kdz7Sj3ERXSjvUwKRlJjzvSp4rTywfq8MvPjYNkBBhMuBHGeFcycg?=
 =?us-ascii?Q?WoT9nSsdH89JiuboUDcXWPxGQO4RUXC2zNFBBsAaDN72kJwxOMUAkOhUhcjk?=
 =?us-ascii?Q?ttKRrkpermB861yw3TSKKJr8J4+rjiPMinto1wah+FLJAy/C+OTWS/WGCl5f?=
 =?us-ascii?Q?IUqVPf2qQtz4X5ZkKe8Sw3AnGvrtDwokP21BNitfLcC6m+xjHnO79ro4kWC/?=
 =?us-ascii?Q?mz9mBP+O/cWVEaEuHp+EhYp0q1B8dmiDpGcpxcYfvFbnV+mtgDZwoQhMpB5R?=
 =?us-ascii?Q?9zWBabBCmYsExBu7NnGkQKKs2dE7PHPIjQiLWIB7yvfFMwl4d9PvRcjSzvZj?=
 =?us-ascii?Q?k9wdhxAxwh1wQJyKX47eHZtRUJsFhdsdyfz0j2XPB/7+xaZIDg4l2wuu/FHl?=
 =?us-ascii?Q?MaLKfjIlF0RACBssXLoIfvEy34TZjnOvOO7ielTkCL9thWrmnV3IeQp1MA7x?=
 =?us-ascii?Q?OYF/ith7bg9wORKvrQoM11x4fKL0/ATDnJLtd8s7+X5ccf4YTmeXxANfJ/Vx?=
 =?us-ascii?Q?OpuaviIwHOd8yV6hdkXMKKVY70Tf/v2Tu5c4TVM3V2FY+Hez0r7DW9ORthdB?=
 =?us-ascii?Q?ZHQa5fEiw3t71fqQmFrvKybR+YCYEIwaz6wY+nQrAOTN8ub/Q+q4FYWy2BA0?=
 =?us-ascii?Q?Xcohym5rMvObhP7r0aFwQs5t/mzm9K1aO+GhM9oGH6xbGOWG4FyGLH5FK5+R?=
 =?us-ascii?Q?lymoLVgAr5xUY9QXS/PkmooHoYseuQ86lo33bVrvMuwwV0GdAy5r9WKjbn3h?=
 =?us-ascii?Q?hGY3om7SM3ViL30CSHSB6T81Lk2aeb7GDGIISMXwyjswBHenYNtV1mWTeAhq?=
 =?us-ascii?Q?warfvUgRfp6VL3fPxyH1oaXIHUPCQ40RhaLwgDZzo0pWWSs5bsQVv+LBZF4r?=
 =?us-ascii?Q?rjy8/B+3f4GWrPJv54W1CmG2Lf3CudcvwfWlqrLv1r/cigcXT2H+eEYvZRgC?=
 =?us-ascii?Q?uxpVgUM/KXFbP3yY9HMuR0W/Sk0SUvXjHabEdn6+IVWmUZE8I83HwaMQ6uIL?=
 =?us-ascii?Q?8TQDsjcMka0ESmESTyX9tbq09YLomXK41V00EEJW4/GdWCyv4XyXfj86sqXc?=
 =?us-ascii?Q?Eg=3D=3D?=
X-OriginatorOrg: oracle.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 20785a39-c3b9-48b5-8180-08da5abfacbb
X-MS-Exchange-CrossTenant-AuthSource: BY5PR10MB4196.namprd10.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 30 Jun 2022 17:40:51.1583
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 4e2c6054-71cb-48f1-bd6c-3a9705aca71b
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: oc907ex9MK2B8h1wTVJU7l2w8uNY0xG+DHqN/NM6TjMvT/i7HHqyArksbbuZjPwBfc5XB7YlJYsds+AMdVbHVw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS7PR10MB5392
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.517,18.0.883
 definitions=2022-06-30_12:2022-06-28,2022-06-30 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxlogscore=999 suspectscore=0
 mlxscore=0 phishscore=0 malwarescore=0 adultscore=0 spamscore=0
 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1
 engine=8.12.0-2204290000 definitions=main-2206300069
X-Proofpoint-ORIG-GUID: L_oTeLOT-4TcYRPSnyMPwraOtQ_wsFD2
X-Proofpoint-GUID: L_oTeLOT-4TcYRPSnyMPwraOtQ_wsFD2
X-Spam-Status: No, score=-2.8 required=5.0 tests=BAYES_00,DKIM_SIGNED,
        DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_LOW,
        RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_NONE,T_SCC_BODY_TEXT_LINE
        autolearn=ham autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on
        lindbergh.monkeyblade.net
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On 06/30/22 09:23, James Houghton wrote:
> On Thu, Jun 30, 2022 at 2:35 AM Muchun Song <songmuchun@bytedance.com> wrote:
> >
> > 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 <mike.kravetz@oracle.com> 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.
> 
> Right -- but I think my point still stands. If `huge_page_size(h)` is
> CONT_PTE_SIZE, then the `pte_t *` passed to `huge_pte_lockptr` will
> *actually* point to a `pte_t` and not a `pmd_t` (I'm pretty sure the
> distinction is important). So it seems like we need to separately keep
> track of the real pmd_t that is being used in the CONT_PTE_SIZE case
> (and therefore, when considering HGM, the PAGE_SIZE case).

Ah yes, that is correct.  We would be passing in a pte not pmd in this
case.

> 
> However, we *can* make this optimization for CONT_PMD_SIZE (maybe this
> is what you originally meant, Muchun?), so instead of
> `huge_page_size(h) == PMD_SIZE`, we could do `huge_page_size(h) >=
> PMD_SIZE && huge_page_size(h) < PUD_SIZE`.
> 

Another 'optimization' may exist in hugetlb address range scanning code.
We currently have something like:

for addr=start, addr< end, addr += huge_page_size
	pte = huge_pte_offset(addr)
	ptl = huge_pte_lock(pte)
	...
	...
	spin_unlock(ptl)

Seems like ptl will be the same for all entries on the same pmd page.
We 'may' be able to go from 512 lock/unlock cycles to 1.
-- 
Mike Kravetz