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:   Wed, 15 Jun 2022 14:22:34 -0700
From:   Mike Kravetz <mike.kravetz@oracle.com>
To:     Baolin Wang <baolin.wang@linux.alibaba.com>
Cc:     linux-kernel@vger.kernel.org, linux-mm@kvack.org,
        Muchun Song <songmuchun@bytedance.com>,
        Michal Hocko <mhocko@suse.com>, Peter Xu <peterx@redhat.com>,
        Naoya Horiguchi <naoya.horiguchi@linux.dev>,
        James Houghton <jthoughton@google.com>,
        Mina Almasry <almasrymina@google.com>,
        "Aneesh Kumar K . V" <aneesh.kumar@linux.vnet.ibm.com>,
        Anshuman Khandual <anshuman.khandual@arm.com>,
        Paul Walmsley <paul.walmsley@sifive.com>,
        Christian Borntraeger <borntraeger@linux.ibm.com>,
        Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [RFC PATCH 1/3] hugetlb: skip to end of PT page mapping when pte
 not present
Message-ID: <YqpNmsLrbCowS1IE@monkey>
References: <20220527225849.284839-1-mike.kravetz@oracle.com>
 <20220527225849.284839-2-mike.kravetz@oracle.com>
 <437e45c5-c46a-46f4-f9cf-d8c2397c988d@linux.alibaba.com>
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <437e45c5-c46a-46f4-f9cf-d8c2397c988d@linux.alibaba.com>
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?PH4fIS+wlQwK+yIU51GOYHaPdK3unjtQogXTrUx6AuEihJRayfag357Fr7B4?=
 =?us-ascii?Q?rxhdKpizrU6e0Z8MUwamXLr1b3R0OSIrLp3KE0bVqri7nFpnU596+IJY5MBv?=
 =?us-ascii?Q?o6GOPtQRUYBRYiJlXQtukrtUke8S0Tt7e20SCmO7Y34j9J/RDD6Yyawk/BAe?=
 =?us-ascii?Q?6yTpOifHQrvp8F1PVFpNnWcSg5ltx2dlPMf65zoGpeaAybUrs4HECtoc8pKf?=
 =?us-ascii?Q?veDboPfhQqhldFwsUxttt/raiXbeQSWBVX63K1yvikiR4nHc7wScQoSuf7Dm?=
 =?us-ascii?Q?fZHHOpjwuYmDYz4V2mN6DBXGaKTwy+m1TNVYN9qUTb+Rm5a3WRU402qNZisQ?=
 =?us-ascii?Q?7h5GI/nvo0T11SThcKg2lW7zKDXc2eeZFA8hMPs/Snx4j45B+7rAqZFY6YQO?=
 =?us-ascii?Q?EKQcmoAJDg9z6KQZjxFCgliprK0U4roV1W2SiiUSb/xn+qRxbLrvfbm7NLtR?=
 =?us-ascii?Q?6bhI8bauTB2CkG4U0ba7s8SUL9l8and9rAurItOT6Hdc2P7Neau91vlysxlw?=
 =?us-ascii?Q?Kz95qHESGZ/WnjI2lCuvJCdulmcznyh2LP53t+QgHzoXE9hll5nzHv64Vag5?=
 =?us-ascii?Q?csOr3x/z4Lz/j+eAOTaWrVmOVrFUXiMQegqapxpjll4mVjlBxz60OFr6oJiq?=
 =?us-ascii?Q?8y+pIB4IOy/H5kvvGcVhVGbWVsnUNGvBrV02jiRgNDC+B3Qu6cCyAlQBENEM?=
 =?us-ascii?Q?/LhJO9wywmwjiv46Kr56WZd2XNnyMWuIJVsliGjitYdqwQihtvvqQjf5oomN?=
 =?us-ascii?Q?zWdQdyTuPdmKSiRCJuLZ7PyU/3WBVORhTgLNSRWjb2ayWPNinidfJbAFq3Xl?=
 =?us-ascii?Q?FpMWqt1Txs7RndrL3DslYNw4XZd5lKUvgihSfRgAbclUdVaqIruHBwbQhdQK?=
 =?us-ascii?Q?jUDmJPGg1FSx+0WxXXUluv+z+HLJPOfU+lISlzTLkKxnQxrJBSThz9C+ttj/?=
 =?us-ascii?Q?jJb+5G+rQXGifppVtM7psoRzolP8xlge1M0XVUeqIDc2bSZsR5FIbOQQAgil?=
 =?us-ascii?Q?RCZSlacS/t5R4Bdp8aPwpCFbT5KfdwMbl7/v1mG3whDp4rH3fIQivt8HevW5?=
 =?us-ascii?Q?XSaga8J+8Zn15w6BeSkaoIpgw5oMXCno7XD9vJKZnri/J3IhvpiDBpveJDPy?=
 =?us-ascii?Q?gw1ME8M2GPz152U1ybO+UxuWU5OesKVXpbt4v8zRI9+X2/fAlxzJAW1MEpZr?=
 =?us-ascii?Q?3lqc62/bNYVNpqyCx/ahwIe4Y5A6IgX/7A/eyI2Uk6yabbzrD+VsTbRBcIos?=
 =?us-ascii?Q?a+6+yodEOWxNacXec8A2jSrlcs/WrSGc1AkxiN2uk9/IIPIYKTKklSNwF8js?=
 =?us-ascii?Q?Ks7+Rm+YlhsnyA+oYgREtv4jtfHXeXMG+lA9H0iMHeu+7VGVyYaoaMPnYIrx?=
 =?us-ascii?Q?BXHnT2Y40O8Wrj6DLGN2C7UYhnh7k0e4cZNDhGsrSijgYlyDW60m4d5mZ1la?=
 =?us-ascii?Q?6FZzqbNb4c7xd8JIWA0Mz2FgGq5EbT2p2Vy4lJZtPbu24DUcJXmec9ZwEbhD?=
 =?us-ascii?Q?KapobY6uNOrCTTTf2w7g52F4cwQbCFBJqGTIDV/svRieiBSVyTDOBbeHWx+R?=
 =?us-ascii?Q?3MYq5XH9Hq13VKpwMACTkLXH5fQ6hlhw1AxKquOaTao3VB60NpHdqpPeANu2?=
 =?us-ascii?Q?BcTW47exMS00gmfQ31v/I2mOiJe4iktOlC2VrSRTUKSgArPhR7t9PcQouD+B?=
 =?us-ascii?Q?zRBnPWzxZpZSZgo53oyjlg1jFIQTrprPSO/QaDdXzeepMUbYrIeffZMuN6dM?=
 =?us-ascii?Q?7MTrqiPM4Et8lSB5Qz1vH2EuyHlLZ68=3D?=
X-OriginatorOrg: oracle.com
X-MS-Exchange-CrossTenant-Network-Message-Id: bea2a71f-6e5b-47f1-725c-08da4f152b8b
X-MS-Exchange-CrossTenant-AuthSource: BY5PR10MB4196.namprd10.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 15 Jun 2022 21:22:37.1218
 (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: VHGvMlOti9MHwXgqGVjYOEyW8UK41YYPDuatWWPG3PRmo+/L9qtNYaU9jCmtXkyWfvx9972glDtg27++hXpEJA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY5PR10MB6143
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.517,18.0.874
 definitions=2022-06-15_07:2022-06-15,2022-06-15 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 malwarescore=0 adultscore=0
 mlxlogscore=999 phishscore=0 mlxscore=0 bulkscore=0 suspectscore=0
 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2204290000
 definitions=main-2206150078
X-Proofpoint-ORIG-GUID: o2wpD86B-g2YzpTQCLZJvwiGfvNw_z2q
X-Proofpoint-GUID: o2wpD86B-g2YzpTQCLZJvwiGfvNw_z2q
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 05/30/22 18:10, Baolin Wang wrote:
> 
> 
> On 5/28/2022 6:58 AM, Mike Kravetz wrote:
> > HugeTLB address ranges are linearly scanned during fork, unmap and
> > remap operations.  If a non-present entry is encountered, the code
> > currently continues to the next huge page aligned address.  However,
> > a non-present entry implies that the page table page for that entry
> > is not present.  Therefore, the linear scan can skip to the end of
> > range mapped by the page table page.  This can speed operations on
> > large sparsely populated hugetlb mappings.
> > 
> > Create a new routine hugetlb_mask_last_hp() that will return an
> > address mask.  When the mask is ORed with an address, the result
> > will be the address of the last huge page mapped by the associated
> > page table page.  Use this mask to update addresses in routines which
> > linearly scan hugetlb address ranges when a non-present pte is
> > encountered.
> > 
> > hugetlb_mask_last_hp is related to the implementation of huge_pte_offset
> > as hugetlb_mask_last_hp is called when huge_pte_offset returns NULL.
> > This patch only provides a complete hugetlb_mask_last_hp implementation
> > when CONFIG_ARCH_WANT_GENERAL_HUGETLB is defined.  Architectures which
> > provide their own versions of huge_pte_offset can also provide their own
> > version of hugetlb_mask_last_hp.
> 
> I tested on my ARM64 machine with implementing arm64 specific
> hugetlb_mask_last_hp() as below, and it works well.
> 
> Just a few nits inline, otherwise looks good to me.
> Tested-by: Baolin Wang <baolin.wang@linux.alibaba.com>
> Reviewed-by: Baolin Wang <baolin.wang@linux.alibaba.com>
> 
> diff --git a/arch/arm64/mm/hugetlbpage.c b/arch/arm64/mm/hugetlbpage.c
> index d93ba128a2b0..e04a097ffcc4 100644
> --- a/arch/arm64/mm/hugetlbpage.c
> +++ b/arch/arm64/mm/hugetlbpage.c
> @@ -376,6 +376,28 @@ pte_t *huge_pte_offset(struct mm_struct *mm,
>         return NULL;
>  }
> 
> +unsigned long hugetlb_mask_last_hp(struct hstate *h)
> +{
> +       unsigned long hp_size = huge_page_size(h);
> +
> +       switch (hp_size) {
> +       case P4D_SIZE:
> +               return PGDIR_SIZE - P4D_SIZE;
> +       case PUD_SIZE:
> +               return P4D_SIZE - PUD_SIZE;
> +       case CONT_PMD_SIZE:
> +               return PUD_SIZE - CONT_PMD_SIZE;
> +       case PMD_SIZE:
> +               return PUD_SIZE - PMD_SIZE;
> +       case CONT_PTE_SIZE:
> +               return PMD_SIZE - CONT_PTE_SIZE;
> +       default:
> +               break;
> +       }
> +
> +       return ~(0UL);
> +}

Hello Baolin,

Would you mind sending this as a proper patch with commit message and
'Signed-off-by:'?  I would like to include it in the upcoming patch series.

-- 
Mike Kravetz