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 B69D4C433EF for ; Fri, 10 Jun 2022 00:08:53 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 1315F8D0067; Thu, 9 Jun 2022 20:08:53 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 0E07F8D0064; Thu, 9 Jun 2022 20:08:53 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id EC31E8D0067; Thu, 9 Jun 2022 20:08:52 -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 D9C3A8D0064 for ; Thu, 9 Jun 2022 20:08:52 -0400 (EDT) Received: from smtpin24.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id B15E4359C8 for ; Fri, 10 Jun 2022 00:08:52 +0000 (UTC) X-FDA: 79560390504.24.83859CD Received: from mail-pg1-f180.google.com (mail-pg1-f180.google.com [209.85.215.180]) by imf21.hostedemail.com (Postfix) with ESMTP id 44D5B1C0081 for ; Fri, 10 Jun 2022 00:08:52 +0000 (UTC) Received: by mail-pg1-f180.google.com with SMTP id 129so23309278pgc.2 for ; Thu, 09 Jun 2022 17:08:52 -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=MaS2sNIkZE7SaWHlKhH/YI3n6sfvjrj5m4CoiaX/33I=; b=VpoCZvxU/FfqoAK+6u/q0PQaH8xPHq9aGSq3ibmyUFsV5U8maoYZCFhq2eV4QfMyj3 7zNBdEtEj7k69gpI3jPAWwyTOjYtHjPWC6AVSU4qXV3dImLX40u2PzYgG5/w68ba2ANM UqjYjj1ohu/VRTi7j5u3gJW28L+zH9a+Eqf0+yrXS0yQExwAS5z+dJOo23doEUPm3NaG s3682kXnrMx4PgecAn6QAU7Pi5pzYkGl5uSyPviRFBwmFBgrPYxdEbygFlbVVRrxumbo zW5n0rC2AbeyHrIEkyRO5T5mZdA67mBNt02hI13DkEiHUYtRKw8OQ16ghDeyjUxm66TP K2vw== 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=MaS2sNIkZE7SaWHlKhH/YI3n6sfvjrj5m4CoiaX/33I=; b=avMeWiIC7Jqc0bUqcx3U/OqdWyQYW1Gd72V0Jun5OwpLFRaSNl758oPFb1UeVWaC4X momWKBRn9f9r3rbz/RcnVwzhaU7Pg/quyufrkUgj7q9qdl7FVmfhjnQd+/YwHiqvJEG8 phUW47ugbpyFmlXbjDh1HE6zOMf6m5jbz8Br+J5ah9xPpqXRe+FlXN6UFdvPEuB2nyL7 Ti1IEpClAxt5DM06T+EjaWJZKVPM04+XLLRppFBhA8xZVFa+qjneaAoqXiG/CNfCrnZC zTnZ9fhalcD/OpAxi0shA8mURICjJkQ94RU9k/XiWYVk/sIajy7MzCnQdGpbxaGUPDdx DFhg== X-Gm-Message-State: AOAM53097wkYk2f9gKwbSAd2+RQgp/7FmTuY6Ir/2zS8Syhec6nZVE4T 6m08M/0lGRVkLdEijLee7WR2sSkijmPVHjP+WdY= X-Google-Smtp-Source: ABdhPJxIojRHgT7HS/v4whlvd9vukX1WNLaaQ0yE6bYAALcB6/ML9ytrMw9rJPQoMc8E3DOA6UhAOPX/1WCKFt2izCs= X-Received: by 2002:a65:67c1:0:b0:3fd:ebd6:5dab with SMTP id b1-20020a6567c1000000b003fdebd65dabmr16367024pgs.75.1654819731056; Thu, 09 Jun 2022 17:08:51 -0700 (PDT) MIME-Version: 1.0 References: <20220606214414.736109-1-shy828301@gmail.com> <20220606214414.736109-3-shy828301@gmail.com> In-Reply-To: From: Yang Shi Date: Thu, 9 Jun 2022 17:08:38 -0700 Message-ID: Subject: Re: [v3 PATCH 2/7] mm: thp: introduce transhuge_vma_size_ok() helper To: "Zach O'Keefe" Cc: Vlastimil Babka , "Kirill A. Shutemov" , Matthew Wilcox , Andrew Morton , Linux MM , Linux Kernel Mailing List Content-Type: text/plain; charset="UTF-8" ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1654819732; 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=MaS2sNIkZE7SaWHlKhH/YI3n6sfvjrj5m4CoiaX/33I=; b=PRoO0bAR6CVJ1TCSTUW0wH9qANiT2Jyb3ptW0sbCd5j4+VxJkzbL5YaxDhipDyRQeGyYbO s1Nz0+B+W6bCU++bZ+7FgnCVDOZKkeGpze5VMbvm5+1PN8tKfmYlbllvFC2vHH6YfhjJEk vVYy4zYx4ndIFfRyolIGNh1Y9tgfP/I= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1654819732; a=rsa-sha256; cv=none; b=Xu+CvkJ1dF1H8tBmDzjHZu9Alv8uOt6fTDdUUYczSwxzM3GBW619+eGPzm5LU2/D9P8quw eO0CUeklHtLJ/sQJkmvvQh/45QYUMuurYf8taZQlrvQTh4J3N79DLBhtP8jvuBmhIhik6k tLrDnHVmmJP4vkXboSwSlHafYguWTu8= ARC-Authentication-Results: i=1; imf21.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=VpoCZvxU; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf21.hostedemail.com: domain of shy828301@gmail.com designates 209.85.215.180 as permitted sender) smtp.mailfrom=shy828301@gmail.com X-Rspamd-Server: rspam11 X-Rspam-User: Authentication-Results: imf21.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=VpoCZvxU; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf21.hostedemail.com: domain of shy828301@gmail.com designates 209.85.215.180 as permitted sender) smtp.mailfrom=shy828301@gmail.com X-Stat-Signature: smkk9nyrdm1n9x3k6n95pe1wnd4wbd56 X-Rspamd-Queue-Id: 44D5B1C0081 X-HE-Tag: 1654819732-589920 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 Thu, Jun 9, 2022 at 3:21 PM Zach O'Keefe wrote: > > On Mon, Jun 6, 2022 at 2:44 PM Yang Shi wrote: > > > > There are couple of places that check whether the vma size is ok for > > THP or not, they are open coded and duplicate, introduce > > transhuge_vma_size_ok() helper to do the job. > > > > Signed-off-by: Yang Shi > > --- > > include/linux/huge_mm.h | 17 +++++++++++++++++ > > mm/huge_memory.c | 5 +---- > > mm/khugepaged.c | 12 ++++++------ > > 3 files changed, 24 insertions(+), 10 deletions(-) > > > > diff --git a/include/linux/huge_mm.h b/include/linux/huge_mm.h > > index 648cb3ce7099..a8f61db47f2a 100644 > > --- a/include/linux/huge_mm.h > > +++ b/include/linux/huge_mm.h > > @@ -116,6 +116,18 @@ extern struct kobj_attribute shmem_enabled_attr; > > > > extern unsigned long transparent_hugepage_flags; > > > > +/* > > + * The vma size has to be large enough to hold an aligned HPAGE_PMD_SIZE area. > > + */ > > +static inline bool transhuge_vma_size_ok(struct vm_area_struct *vma) > > +{ > > + if (round_up(vma->vm_start, HPAGE_PMD_SIZE) < > > + (vma->vm_end & HPAGE_PMD_MASK)) > > + return true; > > + > > + return false; > > +} > > First time coming across round_up() - thanks for that - but for > symmetry, maybe also use round_down() for the end? No strong opinion - > just a suggestion given I've just discovered it. Yeah, round_down is fine too. > > > static inline bool transhuge_vma_suitable(struct vm_area_struct *vma, > > unsigned long addr) > > { > > @@ -345,6 +357,11 @@ static inline bool transparent_hugepage_active(struct vm_area_struct *vma) > > return false; > > } > > > > +static inline bool transhuge_vma_size_ok(struct vm_area_struct *vma) > > +{ > > + return false; > > +} > > + > > static inline bool transhuge_vma_suitable(struct vm_area_struct *vma, > > unsigned long addr) > > { > > diff --git a/mm/huge_memory.c b/mm/huge_memory.c > > index 48182c8fe151..36ada544e494 100644 > > --- a/mm/huge_memory.c > > +++ b/mm/huge_memory.c > > @@ -71,10 +71,7 @@ unsigned long huge_zero_pfn __read_mostly = ~0UL; > > > > bool transparent_hugepage_active(struct vm_area_struct *vma) > > { > > - /* The addr is used to check if the vma size fits */ > > - unsigned long addr = (vma->vm_end & HPAGE_PMD_MASK) - HPAGE_PMD_SIZE; > > - > > - if (!transhuge_vma_suitable(vma, addr)) > > + if (!transhuge_vma_size_ok(vma)) > > return false; > > if (vma_is_anonymous(vma)) > > return __transparent_hugepage_enabled(vma); > > Do we need a check for vma->vm_pgoff alignment here, after > !vma_is_anonymous(), and now that we don't call > transhuge_vma_suitable()? Actually I was thinking about this too. But the THPeligible bit shown by smaps is a little bit ambiguous for file vma. The document says: "THPeligible" indicates whether the mapping is eligible for allocating THP pages - 1 if true, 0 otherwise. Even though it doesn't fulfill the alignment, it is still possible to get THP allocated, but just can't be PMD mapped. So the old behavior of THPeligible for file vma seems problematic, or at least doesn't match the document. I should elaborate this in the commit log. > > > diff --git a/mm/khugepaged.c b/mm/khugepaged.c > > index 84b9cf4b9be9..d0f8020164fc 100644 > > --- a/mm/khugepaged.c > > +++ b/mm/khugepaged.c > > @@ -454,6 +454,9 @@ bool hugepage_vma_check(struct vm_area_struct *vma, > > vma->vm_pgoff, HPAGE_PMD_NR)) > > return false; > > > > + if (!transhuge_vma_size_ok(vma)) > > + return false; > > + > > /* Enabled via shmem mount options or sysfs settings. */ > > if (shmem_file(vma->vm_file)) > > return shmem_huge_enabled(vma); > > @@ -512,9 +515,7 @@ void khugepaged_enter_vma(struct vm_area_struct *vma, > > unsigned long 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))) { > > + khugepaged_enabled()) { > > if (hugepage_vma_check(vma, vm_flags)) > > __khugepaged_enter(vma->vm_mm); > > } > > @@ -2142,10 +2143,9 @@ static unsigned int khugepaged_scan_mm_slot(unsigned int pages, > > progress++; > > continue; > > } > > - hstart = (vma->vm_start + ~HPAGE_PMD_MASK) & HPAGE_PMD_MASK; > > + > > + hstart = round_up(vma->vm_start, HPAGE_PMD_SIZE); > > hend = vma->vm_end & HPAGE_PMD_MASK; > > - if (hstart >= hend) > > - goto skip; > > if (khugepaged_scan.address > hend) > > goto skip; > > if (khugepaged_scan.address < hstart) > > Likewise, could do round_down() here (just a suggestion) Fine to me. > > > -- > > 2.26.3 > > > >