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 F0E41C433F5 for ; Wed, 9 Feb 2022 08:21:25 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 595B66B0073; Wed, 9 Feb 2022 03:21:25 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 546C36B0074; Wed, 9 Feb 2022 03:21:25 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 4336E6B0075; Wed, 9 Feb 2022 03:21:25 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0150.hostedemail.com [216.40.44.150]) by kanga.kvack.org (Postfix) with ESMTP id 3412F6B0073 for ; Wed, 9 Feb 2022 03:21:25 -0500 (EST) Received: from smtpin29.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id E61ED93684 for ; Wed, 9 Feb 2022 08:21:24 +0000 (UTC) X-FDA: 79122546888.29.CEE3822 Received: from mail-qk1-f179.google.com (mail-qk1-f179.google.com [209.85.222.179]) by imf10.hostedemail.com (Postfix) with ESMTP id 9073BC0003 for ; Wed, 9 Feb 2022 08:21:24 +0000 (UTC) Received: by mail-qk1-f179.google.com with SMTP id o12so1018396qke.5 for ; Wed, 09 Feb 2022 00:21:24 -0800 (PST) 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:content-transfer-encoding; bh=CCbpx5jLa8X1+FwaGeKkcnSoDsrgs8CZ2w84UAyChHY=; b=Nhj/ZnNwDFrpkYBY6DFEhSraKBvoCLj+dlO0F2AxKmk5foXNQ4tLGE0D2Uc37U8GuH ZwytMM06AwWqDvKV3b8Zp5A2QGAXOTvwSLRuPLDb05AhSMgeCNdkCXuYota+XlkP34MV MmcolkIINxwmdDVOFCBpwbuJxcbev6t5BPg+xLVZKjl8bkedj2xlYiBM19JIneqyLYq8 LCw7BrEOBxMIqOg0uhRLsVh2z2ZMaLZCD1x1Mwa4kJ4ouxVjLMkwQTWpo6NGoVlh94TM CnpLAJIYtyCHrIeQJXt4j1QRqBuEEfH4x3PA6TBXEr+zNeEUxhjj2WOu5annwamaqXip PqNg== X-Gm-Message-State: AOAM530deiXZmIcXp9qWRMS7GnZ06T5eu9zFaL26UKvvR+MOJhff89hy pdPV7qkrnqqTxldpOsEOcIeqghLPOEyoZg== X-Google-Smtp-Source: ABdhPJwcVEJpR1TmX2ZsZb/QqgfpCI0hwft1pienAi+ce/M1fW3EbwA0I3YYfiPKLpTLoYNyPwHfjg== X-Received: by 2002:a37:a254:: with SMTP id l81mr475948qke.682.1644394883519; Wed, 09 Feb 2022 00:21:23 -0800 (PST) Received: from mail-qv1-f52.google.com (mail-qv1-f52.google.com. [209.85.219.52]) by smtp.gmail.com with ESMTPSA id d17sm8428310qkn.84.2022.02.09.00.21.23 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 09 Feb 2022 00:21:23 -0800 (PST) Received: by mail-qv1-f52.google.com with SMTP id d7so1225962qvk.2 for ; Wed, 09 Feb 2022 00:21:23 -0800 (PST) X-Received: by 2002:a1f:2555:: with SMTP id l82mr414163vkl.7.1644394550779; Wed, 09 Feb 2022 00:15:50 -0800 (PST) MIME-Version: 1.0 References: <8e4356d-9622-a7f0-b2c-f116b5f2efea@google.com> In-Reply-To: From: Geert Uytterhoeven Date: Wed, 9 Feb 2022 09:15:39 +0100 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH 10/13] mm/munlock: mlock_page() munlock_page() batch by pagevec To: Hugh Dickins Cc: Andrew Morton , Michal Hocko , Vlastimil Babka , "Kirill A. Shutemov" , Matthew Wilcox , David Hildenbrand , Alistair Popple , Johannes Weiner , Rik van Riel , Suren Baghdasaryan , Yu Zhao , Greg Thelen , Shakeel Butt , Linux Kernel Mailing List , Linux MM Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Stat-Signature: f466iuto5qq5g98t9egqu18ygbkshncx X-Rspam-User: Authentication-Results: imf10.hostedemail.com; dkim=none; dmarc=none; spf=pass (imf10.hostedemail.com: domain of geert.uytterhoeven@gmail.com designates 209.85.222.179 as permitted sender) smtp.mailfrom=geert.uytterhoeven@gmail.com X-Rspamd-Server: rspam08 X-Rspamd-Queue-Id: 9073BC0003 X-HE-Tag: 1644394884-352337 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: Hi Hugh, On Wed, Feb 9, 2022 at 3:46 AM Hugh Dickins wrote: > A weakness of the page->mlock_count approach is the need for lruvec lock > while holding page table lock. That is not an overhead we would allow on > normal pages, but I think acceptable just for pages in an mlocked area. > But let's try to amortize the extra cost by gathering on per-cpu pagevec > before acquiring the lruvec lock. > > I have an unverified conjecture that the mlock pagevec might work out > well for delaying the mlock processing of new file pages until they have > got off lru_cache_add()'s pagevec and on to LRU. > > The initialization of page->mlock_count is subject to races and awkward: > 0 or !!PageMlocked or 1? Was it wrong even in the implementation before > this commit, which just widens the window? I haven't gone back to think > it through. Maybe someone can point out a better way to initialize it. > > Bringing lru_cache_add_inactive_or_unevictable()'s mlock initialization > into mm/mlock.c has helped: mlock_new_page(), using the mlock pagevec, > rather than lru_cache_add()'s pagevec. > > Experimented with various orderings: the right thing seems to be for > mlock_page() and mlock_new_page() to TestSetPageMlocked before adding to > pagevec, but munlock_page() to leave TestClearPageMlocked to the later > pagevec processing. > > Dropped the VM_BUG_ON_PAGE(PageTail)s this time around: they have made > their point, and the thp_nr_page()s already contain a VM_BUG_ON_PGFLAGS() > for that. > > This still leaves acquiring lruvec locks under page table lock each time > the pagevec fills (or a THP is added): which I suppose is rather silly, > since they sit on pagevec waiting to be processed long after page table > lock has been dropped; but I'm disinclined to uglify the calling sequence > until some load shows an actual problem with it (nothing wrong with > taking lruvec lock under page table lock, just "nicer" to do it less). > > Signed-off-by: Hugh Dickins Thanks for your patch, which is now commit cbaf47432c909044 ("mm/munlock: mlock_page() munlock_page() batch by pagevec") in next-20220209. > --- a/mm/internal.h > +++ b/mm/internal.h > @@ -402,7 +402,8 @@ extern int mlock_future_check(struct mm_struct *mm, u= nsigned long flags, > * > * mlock is usually called at the end of page_add_*_rmap(), > * munlock at the end of page_remove_rmap(); but new anon > - * pages are managed in lru_cache_add_inactive_or_unevictable(). > + * pages are managed by lru_cache_add_inactive_or_unevictable() > + * calling mlock_new_page(). > * > * @compound is used to include pmd mappings of THPs, but filter out > * pte mappings of THPs, which cannot be consistently counted: a pte > @@ -425,6 +426,9 @@ static inline void munlock_vma_page(struct page *page= , > (compound || !PageTransCompound(page))) > munlock_page(page); > } > +void mlock_new_page(struct page *page); > +bool need_mlock_page_drain(int cpu); > +void mlock_page_drain(int cpu); This is inside an #ifdef CONFIG_MMU section. > --- a/mm/swap.c > +++ b/mm/swap.c > @@ -640,6 +634,7 @@ void lru_add_drain_cpu(int cpu) > pagevec_lru_move_fn(pvec, lru_lazyfree_fn); > > activate_page_drain(cpu); > + mlock_page_drain(cpu); noreply@ellerman.id.au reported for m5272c3_defconfig: mm/swap.c:637:2: error: implicit declaration of function =E2=80=98mlock_page_drain=E2=80=99 [-Werror=3Dimplicit-function-declaration= ] http://kisskb.ellerman.id.au/kisskb/buildresult/14694567/ Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k= .org In personal conversations with technical people, I call myself a hacker. Bu= t when I'm talking to journalists I just say "programmer" or something like t= hat. -- Linus Torvalds