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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id BB41FC433F5 for ; Mon, 28 Mar 2022 22:12:04 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229560AbiC1WNn (ORCPT ); Mon, 28 Mar 2022 18:13:43 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37872 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229561AbiC1WN1 (ORCPT ); Mon, 28 Mar 2022 18:13:27 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E5A82694A3 for ; Mon, 28 Mar 2022 15:02:34 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id C36A2B81259 for ; Mon, 28 Mar 2022 21:54:51 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 64C75C340ED; Mon, 28 Mar 2022 21:54:50 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org; s=korg; t=1648504490; bh=tiGvKyyMvOaqyMDQHmK8mz3vuJd0MWfBLha7EOr1Y7w=; h=Date:To:From:Subject:From; b=ISIgh+ZxKP3GJcl77xFFasxk/ikVgmFlKWrBbOoPGupK9PV4mJlumWxoxyflaClss i+GSg8pjSB8QfX3gCIyTLQJfvFmY6wA9s25JlVrNKwGWCBKo1t4YSFf2Cp3PU7z0OE jtA69YwvhKaWwQ+9QAKUglzBv+MTCEQapue+MWQc= Date: Mon, 28 Mar 2022 14:54:49 -0700 To: mm-commits@vger.kernel.org, vbabka@suse.cz, efault@gmx.de, hughd@google.com, akpm@linux-foundation.org From: Andrew Morton Subject: + mm-munlock-add-lru_add_drain-to-fix-memcg_stat_test.patch added to -mm tree Message-Id: <20220328215450.64C75C340ED@smtp.kernel.org> Precedence: bulk Reply-To: linux-kernel@vger.kernel.org List-ID: X-Mailing-List: mm-commits@vger.kernel.org The patch titled Subject: mm/munlock: add lru_add_drain() to fix memcg_stat_test has been added to the -mm tree. Its filename is mm-munlock-add-lru_add_drain-to-fix-memcg_stat_test.patch This patch should soon appear at https://ozlabs.org/~akpm/mmots/broken-out/mm-munlock-add-lru_add_drain-to-fix-memcg_stat_test.patch and later at https://ozlabs.org/~akpm/mmotm/broken-out/mm-munlock-add-lru_add_drain-to-fix-memcg_stat_test.patch Before you just go and hit "reply", please: a) Consider who else should be cc'ed b) Prefer to cc a suitable mailing list as well c) Ideally: find the original patch on the mailing list and do a reply-to-all to that, adding suitable additional cc's *** Remember to use Documentation/process/submit-checklist.rst when testing your code *** The -mm tree is included into linux-next and is updated there every 3-4 working days ------------------------------------------------------ From: Hugh Dickins Subject: mm/munlock: add lru_add_drain() to fix memcg_stat_test Mike reports that LTP memcg_stat_test usually leads to... memcg_stat_test 3 TINFO: Test unevictable with MAP_LOCKED memcg_stat_test 3 TINFO: Running memcg_process --mmap-lock1 -s 135168 memcg_stat_test 3 TINFO: Warming up pid: 3460 memcg_stat_test 3 TINFO: Process is still here after warm up: 3460 memcg_stat_test 3 TFAIL: unevictable is 122880, 135168 expected ...but may lead to... memcg_stat_test 4 TINFO: Test unevictable with mlock memcg_stat_test 4 TINFO: Running memcg_process --mmap-lock2 -s 135168 memcg_stat_test 4 TINFO: Warming up pid: 4271 memcg_stat_test 4 TINFO: Process is still here after warm up: 4271 memcg_stat_test 4 TFAIL: unevictable is 122880, 135168 expected ...or both. A wee bit flaky. follow_page_pte() used to have an lru_add_drain() per each page mlocked, and the test came to rely on accurate stats. The pagevec to be drained is different now, but still covered by lru_add_drain(); and, never mind the test, I believe it's in everyone's interest that a bulk faulting interface like populate_vma_page_range() or faultin_vma_page_range() should drain its local pagevecs at the end, to save others sometimes needing the much more expensive lru_add_drain_all(). This does not absolutely guarantee exact stats - the mlocking task can be migrated between CPUs as it proceeds - but it's good enough and the tests pass. Link: https://lkml.kernel.org/r/47f6d39c-a075-50cb-1cfb-26dd957a48af@google.com Fixes: b67bf49ce7aa ("mm/munlock: delete FOLL_MLOCK and FOLL_POPULATE") Signed-off-by: Hugh Dickins Reported-by: Mike Galbraith Cc: Vlastimil Babka Signed-off-by: Andrew Morton --- mm/gup.c | 10 ++++++++-- 1 file changed, 8 insertions(+), 2 deletions(-) --- a/mm/gup.c~mm-munlock-add-lru_add_drain-to-fix-memcg_stat_test +++ a/mm/gup.c @@ -1404,6 +1404,7 @@ long populate_vma_page_range(struct vm_a struct mm_struct *mm = vma->vm_mm; unsigned long nr_pages = (end - start) / PAGE_SIZE; int gup_flags; + long ret; VM_BUG_ON(!PAGE_ALIGNED(start)); VM_BUG_ON(!PAGE_ALIGNED(end)); @@ -1438,8 +1439,10 @@ long populate_vma_page_range(struct vm_a * We made sure addr is within a VMA, so the following will * not result in a stack expansion that recurses back here. */ - return __get_user_pages(mm, start, nr_pages, gup_flags, + ret = __get_user_pages(mm, start, nr_pages, gup_flags, NULL, NULL, locked); + lru_add_drain(); + return ret; } /* @@ -1471,6 +1474,7 @@ long faultin_vma_page_range(struct vm_ar struct mm_struct *mm = vma->vm_mm; unsigned long nr_pages = (end - start) / PAGE_SIZE; int gup_flags; + long ret; VM_BUG_ON(!PAGE_ALIGNED(start)); VM_BUG_ON(!PAGE_ALIGNED(end)); @@ -1498,8 +1502,10 @@ long faultin_vma_page_range(struct vm_ar if (check_vma_flags(vma, gup_flags)) return -EINVAL; - return __get_user_pages(mm, start, nr_pages, gup_flags, + ret = __get_user_pages(mm, start, nr_pages, gup_flags, NULL, NULL, locked); + lru_add_drain(); + return ret; } /* _ Patches currently in -mm which might be from hughd@google.com are mm-munlock-remove-fields-to-fix-htmldocs-warnings.patch mm-munlock-add-lru_add_drain-to-fix-memcg_stat_test.patch