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 X-Spam-Level: X-Spam-Status: No, score=-12.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 66320C433B4 for ; Tue, 6 Apr 2021 21:05:01 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id DF69361284 for ; Tue, 6 Apr 2021 21:05:00 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org DF69361284 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 53EC86B007E; Tue, 6 Apr 2021 17:05:00 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 4EE656B0080; Tue, 6 Apr 2021 17:05:00 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 38EC66B0081; Tue, 6 Apr 2021 17:05:00 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0028.hostedemail.com [216.40.44.28]) by kanga.kvack.org (Postfix) with ESMTP id 1DB436B007E for ; Tue, 6 Apr 2021 17:05:00 -0400 (EDT) Received: from smtpin39.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id C38A71730875 for ; Tue, 6 Apr 2021 21:04:59 +0000 (UTC) X-FDA: 78003171918.39.7A1EAC1 Received: from mail-ej1-f49.google.com (mail-ej1-f49.google.com [209.85.218.49]) by imf24.hostedemail.com (Postfix) with ESMTP id ED271A000396 for ; Tue, 6 Apr 2021 21:04:55 +0000 (UTC) Received: by mail-ej1-f49.google.com with SMTP id u5so24142403ejn.8 for ; Tue, 06 Apr 2021 14:04:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=+joV+qmAQTX6W5D3ult4hJeoWrn1GtjQphIjc6QUDxI=; b=o0Wne08IYo8GRQHbrIO11Ao58rWJ1IwKE8wsCtFNNWepfoVVyUe2rSMttI8A2tFlHv rKndxv4Aiy/sGI78RU1VQsnJPZB+2/484cCVlFb/1W2uTtgmlq62eopat5LuicFaGshW ONKxVO17t/L9ygq7tT4vAoURr+Qsz8qeaA4jboyLP8soPHzi7OjLo4OmaWFN3ZKrQT/q pZT3xyOZV0EpW0zBjT8EASLMUfhNkVR1hQJOo1BtdpUq6Flc32pa+gj+bBo1N3cgoMhC XvHGDqfiA42fBy2ciR/lpq+kwbrLO8SzyxNU0lYObrqVygxYqsImsdzawR3FvkU8Z878 DP9w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=+joV+qmAQTX6W5D3ult4hJeoWrn1GtjQphIjc6QUDxI=; b=Do0i7tAE8Ti1Axfh1lt2GZJaj7oio1EGlJoNzu8qKgvLKyA7jYoV31tBb//lItlvvG vaWQL6CPoLS3CHMx31IlF0h1fqeB01tAeRQH+ngsQKyt+x4HJClKg1QUt7XqbJw4ovmw YyPBiQbT2FSHlumvs6ks0VRHif5nh0sMLqdwgVUVyt+UhWeaiN560+gFCrKPMVGJp7oG YOeECS1rXFDq7Efh3m8AXDerrgasJJfHj1xmKrYUn5l8UZUmIsTxRxCkBAqnEcnY5fD2 GEC2fh/kVhuuzbA9sV7V8/3U85LDMSQpRvteo2OdUfrSgxuejIwgF9Ix2RXoYiiCbT+c 4x7w== X-Gm-Message-State: AOAM530+0D5R6BoHr1IBVPOEwJisQN5YjwF/1vdXnleLHSgWeuwJMeYM sE0LnvSGnSeASmO/vGkSHWijGQMxKG9G3pSCiHs= X-Google-Smtp-Source: ABdhPJx++EtRbXkk8rcqprgz5WDhhuyU8NprIgw4QUprSaRB29XyhBJim/pfK9Zu3YxyrlFKXoAYsh3QZDS9EXv9bys= X-Received: by 2002:a17:906:a51:: with SMTP id x17mr36694251ejf.25.1617743098057; Tue, 06 Apr 2021 14:04:58 -0700 (PDT) MIME-Version: 1.0 References: <20210404153311.1460106-1-yanfei.xu@windriver.com> <20210404153311.1460106-3-yanfei.xu@windriver.com> <6d188d5b-94d0-1606-52c2-a3e0b6455a27@windriver.com> In-Reply-To: <6d188d5b-94d0-1606-52c2-a3e0b6455a27@windriver.com> From: Yang Shi Date: Tue, 6 Apr 2021 14:04:46 -0700 Message-ID: Subject: Re: [PATCH 2/2] mm: khugepaged: check MMF_DISABLE_THP ahead of iterating over vmas To: "Xu, Yanfei" Cc: Linux MM , Linux Kernel Mailing List Content-Type: text/plain; charset="UTF-8" X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: ED271A000396 X-Stat-Signature: gb7yfxqh856tkxkrrqyp35wsmiqw4rum Received-SPF: none (gmail.com>: No applicable sender policy available) receiver=imf24; identity=mailfrom; envelope-from=""; helo=mail-ej1-f49.google.com; client-ip=209.85.218.49 X-HE-DKIM-Result: pass/pass X-HE-Tag: 1617743095-692775 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 Mon, Apr 5, 2021 at 8:05 PM Xu, Yanfei wrote: > > > > On 4/6/21 10:51 AM, Xu, Yanfei wrote: > > > > > > On 4/6/21 2:20 AM, Yang Shi wrote: > >> [Please note: This e-mail is from an EXTERNAL e-mail address] > >> > >> On Sun, Apr 4, 2021 at 8:33 AM wrote: > >>> > >>> From: Yanfei Xu > >>> > >>> We could check MMF_DISABLE_THP ahead of iterating over all of vma. > >>> Otherwise if some mm_struct contain a large number of vma, there will > >>> be amounts meaningless cpu cycles cost. > >>> > >>> BTW, drop an unnecessary cond_resched(), because there is a another > >>> cond_resched() followed it and no consumed invocation between them. > >>> > >>> Signed-off-by: Yanfei Xu > >>> --- > >>> mm/khugepaged.c | 3 ++- > >>> 1 file changed, 2 insertions(+), 1 deletion(-) > >>> > >>> diff --git a/mm/khugepaged.c b/mm/khugepaged.c > >>> index 2efe1d0c92ed..c293ec4a94ea 100644 > >>> --- a/mm/khugepaged.c > >>> +++ b/mm/khugepaged.c > >>> @@ -2094,6 +2094,8 @@ static unsigned int > >>> khugepaged_scan_mm_slot(unsigned int pages, > >>> */ > >>> if (unlikely(!mmap_read_trylock(mm))) > >>> goto breakouterloop_mmap_lock; > >>> + if (test_bit(MMF_DISABLE_THP, &mm->flags)) > >>> + goto breakouterloop_mmap_lock; > >> > >> It is fine to check this flag. But mmap_lock has been acquired so you > >> should jump to breakouterloop. > > > > Oops! It's my fault. Thank you for pointing out this. > > Will fix it in v2. > > > >> > >>> if (likely(!khugepaged_test_exit(mm))) > >>> vma = find_vma(mm, khugepaged_scan.address); > >>> > >>> @@ -2101,7 +2103,6 @@ static unsigned int > >>> khugepaged_scan_mm_slot(unsigned int pages, > >>> for (; vma; vma = vma->vm_next) { > >>> unsigned long hstart, hend; > >>> > >>> - cond_resched(); > >> > >> I don't have a strong opinion for removing this cond_resched(). But > >> IIUC khugepaged is a best effort job there is no harm to keep it IMHO. > >> > > > > Yes, keeping it is no harm. But I think we should add it when we need. > > Look at the blow codes, there are only some simple check between these > > two cond_resched(). And we still have some cond_resched() in the > > khugepaged_scan_file() and khugepaged_scan_pmd() which is the actual > > wrok about collapsing. So I think it is unnecessary. :) > > > > BTW, the original author add this cond_resched() might be worry about > the hugepage_vma_check() always return false due to the MMF_DISABLE_THP. > But now we have moved it out of the for loop of iterating vma. A little bit of archeology showed the cond_resched() was there in the first place even before MMF_DISABLE_THP was introduced. > > um.. That is my guess.. > > Thanks, > Yanfei > > > for (; vma; vma = vma->vm_next) { > > unsigned long hstart, hend; > > > > cond_resched(); //here > > if (unlikely(khugepaged_test_exit(mm))) { > > progress++; > > break; > > } > > if (!hugepage_vma_check(vma, vma->vm_flags)) { > > skip: > > progress++; > > continue; > > } > > hstart = ALIGN(vma->vm_start, HPAGE_PMD_SIZE); > > hend = ALIGN_DOWN(vma->vm_end, HPAGE_PMD_SIZE); > > if (hstart >= hend) > > goto skip; > > if (khugepaged_scan.address > hend) > > goto skip; > > if (khugepaged_scan.address < hstart) > > khugepaged_scan.address = hstart; > > VM_BUG_ON(!IS_ALIGNED(khugepaged_scan.address, > > HPAGE_PMD_SIZE)); > > > > if (shmem_file(vma->vm_file) && !shmem_huge_enabled(vma)) > > goto skip; > > > > while (khugepaged_scan.address < hend) { > > int ret; > > cond_resched(); //here > > > > > >>> if (unlikely(khugepaged_test_exit(mm))) { > >>> progress++; > >>> break; > >>> -- > >>> 2.27.0 > >>> > >>>