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 02137C433EF for ; Tue, 10 May 2022 22:35:27 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 6F3A26B0071; Tue, 10 May 2022 18:35:27 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 679426B0072; Tue, 10 May 2022 18:35:27 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 4CBCC6B0073; Tue, 10 May 2022 18:35:27 -0400 (EDT) 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 352D16B0071 for ; Tue, 10 May 2022 18:35:27 -0400 (EDT) Received: from smtpin29.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 0A044315C5 for ; Tue, 10 May 2022 22:35:27 +0000 (UTC) X-FDA: 79451291094.29.858381D Received: from mail-pl1-f169.google.com (mail-pl1-f169.google.com [209.85.214.169]) by imf01.hostedemail.com (Postfix) with ESMTP id 1955D400A9 for ; Tue, 10 May 2022 22:35:14 +0000 (UTC) Received: by mail-pl1-f169.google.com with SMTP id q18so100613pln.12 for ; Tue, 10 May 2022 15:35:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=iYf8+0BM+nZESEiOImBjsOdYHgGG/iLfKQrj/8qf7rA=; b=YZmXj+oWML4GDMo1EQd1cGPNRTin0KiSIBmHWoG6suNlLeXmjJBdewWHfJF+Uj4I1D qtjuJ3SAtF1QaXb8vt91KjCEmmqXNS6Mmg01VlrXCiyVSjrUKUERm9REZM/Tpa8DYo8p Go4BiOwi6wywh776otZ6RoL6/luSTUr2+Wnavg9Z7oidP5XdOfrT6UJOpUR4bUCYj/EZ O2pnPWBs5CRROSfloEEZ4IX47360DB6msOuNtM5gvEdsa+ZisKbf5Kio6nenwWKkNOJg 1ui0oMKH2nf24n48kgEdtOoyYX6VhGLnKtbF8CP1/hQh9ZM4/SfglrZdXHDYkZJ54up2 l3MA== 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=iYf8+0BM+nZESEiOImBjsOdYHgGG/iLfKQrj/8qf7rA=; b=gs6RrpxrJN/xGD5++oz8tn6ssI1yb4rv3vSDE85vq7ZwErP+vmGNB2GZuIhcYU3NwZ hPqpTC2jEiQEbkbVm4szBMwdHqB0sd3TfyX47RNUF3/z5FDitoY32ca03Of3DBw2CePM IfG9xKyiBl0zsoTSSVKV4WHw2kROf5uWFXcSddaDPz7C97oqsEp6qCG3JUDo7CvjjUTX vo6Onmqc7bgJo//kUB8Y9MtkucWK/BKGMUhoou84WpfG2odmBvUmwd7uIzqnUFwmOkhB KjfIGDFHskH47B+Xi8Zb3Kvhr+prgg6WnkAKWkb0SIjumt3UmPra30TiiCdCW66veD04 oiLA== X-Gm-Message-State: AOAM530J3DymVijlIJtV7F/Sq8JWzohf89HHJJXwf0H5XbO72v6EwIBJ sPfnJ9+rkgbsf+c2vAERY09CluaPMDJF7OogzA4= X-Google-Smtp-Source: ABdhPJyh5t+bk2Eu+iP0jde1ku+eqTCWsVCDbFvUnejEWS8YDaqj7z3ufCWJqg274m8z7C1bobG9DHlAoCZJaUofVK8= X-Received: by 2002:a17:90b:1b52:b0:1dc:54ea:ac00 with SMTP id nv18-20020a17090b1b5200b001dc54eaac00mr2061327pjb.99.1652222125619; Tue, 10 May 2022 15:35:25 -0700 (PDT) MIME-Version: 1.0 References: <20220510203222.24246-1-shy828301@gmail.com> <20220510203222.24246-7-shy828301@gmail.com> <20220510140545.5dd9d3145b53cb7e226c236a@linux-foundation.org> In-Reply-To: <20220510140545.5dd9d3145b53cb7e226c236a@linux-foundation.org> From: Yang Shi Date: Tue, 10 May 2022 15:35:13 -0700 Message-ID: Subject: Re: [v4 PATCH 6/8] mm: khugepaged: make hugepage_vma_check() non-static To: Andrew Morton Cc: Vlastimil Babka , "Kirill A. Shutemov" , Miaohe Lin , Song Liu , Rik van Riel , Matthew Wilcox , Zi Yan , "Theodore Ts'o" , Linux MM , Linux FS-devel Mailing List , Linux Kernel Mailing List Content-Type: text/plain; charset="UTF-8" X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: 1955D400A9 X-Stat-Signature: 1ebb4ybt8k7b4mi674ie7u3jr59buzz6 Authentication-Results: imf01.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=YZmXj+oW; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf01.hostedemail.com: domain of shy828301@gmail.com designates 209.85.214.169 as permitted sender) smtp.mailfrom=shy828301@gmail.com X-Rspam-User: X-HE-Tag: 1652222114-510573 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 Tue, May 10, 2022 at 2:05 PM Andrew Morton wrote: > > On Tue, 10 May 2022 13:32:20 -0700 Yang Shi wrote: > > > The hugepage_vma_check() could be reused by khugepaged_enter() and > > khugepaged_enter_vma_merge(), but it is static in khugepaged.c. > > Make it non-static and declare it in khugepaged.h. > > > > .. > > > > @@ -508,20 +508,13 @@ void __khugepaged_enter(struct mm_struct *mm) > > void khugepaged_enter_vma_merge(struct vm_area_struct *vma, > > unsigned long vm_flags) > > { > > - unsigned long hstart, hend; > > - > > - /* > > - * khugepaged only supports read-only files for non-shmem files. > > - * khugepaged does not yet work on special mappings. And > > - * file-private shmem THP is not supported. > > - */ > > - if (!hugepage_vma_check(vma, vm_flags)) > > - return; > > - > > - hstart = (vma->vm_start + ~HPAGE_PMD_MASK) & HPAGE_PMD_MASK; > > - hend = vma->vm_end & HPAGE_PMD_MASK; > > - if (hstart < hend) > > - khugepaged_enter(vma, vm_flags); > > + if (!test_bit(MMF_VM_HUGEPAGE, &vma->vm_mm->flags) && > > + khugepaged_enabled() && > > + (((vma->vm_start + ~HPAGE_PMD_MASK) & HPAGE_PMD_MASK) < > > + (vma->vm_end & HPAGE_PMD_MASK))) { > > Reviewing these bounds-checking tests is so hard :( Can we simplify? Yeah, I think they can be moved into a helper with a more descriptive name. > > > + if (hugepage_vma_check(vma, vm_flags)) > > + __khugepaged_enter(vma->vm_mm); > > + } > > } > > void khugepaged_enter_vma(struct vm_area_struct *vma, > unsigned long vm_flags) > { > if (test_bit(MMF_VM_HUGEPAGE, &vma->vm_mm->flags)) > return; > if (!khugepaged_enabled()) > return; > if (round_up(vma->vm_start, HPAGE_PMD_SIZE) >= > (vma->vm_end & HPAGE_PMD_MASK)) > return; /* vma is too small */ > if (!hugepage_vma_check(vma, vm_flags)) > return; > __khugepaged_enter(vma->vm_mm); > } > > > Also, it might be slightly faster to have checked MMF_VM_HUGEPAGE > before khugepaged_enabled(), but it looks odd. And it might be slower, > too - more pointer chasing. I think most configurations have always or madvise mode set (khugepaged_enabled() return true), so having checked MMF_VM_HUGEPAGE before khugepaged_enabled() seems slightly better, but anyway it should not have measurable effect IMHO. > > I wish someone would document hugepage_vma_check(). I will clean up all the stuff further in a new patchset, for example, trying to consolidate all the different hugepage_suitable/enabled/active checks.