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 E8F5FC433F5 for ; Mon, 14 Feb 2022 05:35:05 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 115196B0072; Mon, 14 Feb 2022 00:35:05 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 0C6156B0073; Mon, 14 Feb 2022 00:35:05 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id ECFE96B0078; Mon, 14 Feb 2022 00:35:04 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (relay.hostedemail.com [64.99.140.27]) by kanga.kvack.org (Postfix) with ESMTP id DA2D06B0072 for ; Mon, 14 Feb 2022 00:35:04 -0500 (EST) Received: from smtpin03.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 8E6FA56F for ; Mon, 14 Feb 2022 05:35:04 +0000 (UTC) X-FDA: 79140271728.03.78A6E5D Received: from mail-oo1-f51.google.com (mail-oo1-f51.google.com [209.85.161.51]) by imf09.hostedemail.com (Postfix) with ESMTP id 1E09E140006 for ; Mon, 14 Feb 2022 05:35:03 +0000 (UTC) Received: by mail-oo1-f51.google.com with SMTP id u25-20020a4ad0d9000000b002e8d4370689so18131018oor.12 for ; Sun, 13 Feb 2022 21:35:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=date:from:to:cc:subject:in-reply-to:message-id:references :mime-version; bh=L7XXqMw0BJqSwPiX8BdrSc7e/KusNkA7RDmHju/xVA8=; b=Av/BOZkalXOtnl373o4nXpwwZIQACBb4OcQ+B0AOpUyLR80QEv/C26HewhnAq6N51D BYt1ZZn1+T/oPQbvb90t3FnCq+rTG9zhZTBx/aD7qKUtYcmkvMXO0Cdku64o8PRDNp2u Rt3N8V9m52xI60oD9qncI93rcNaTBZP9dR3ZiiOPWZlZ9Dtnv2KKUlPaYBU/9SOBQj5I +tyO5tsEwGwOPKknhsP9+xGC/HAbE18v7XxM36ThGlDB0+T2+FZC7cafv3sphrDlz4RA puUPUAxLwANnO0HXMNM5cKuCjhVLbqiGYlCGMfXFZguGi9ZPc60I8a96hI4A2wJkocLK PvRA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:in-reply-to:message-id :references:mime-version; bh=L7XXqMw0BJqSwPiX8BdrSc7e/KusNkA7RDmHju/xVA8=; b=5N4xFQAxnAHev2Ynxzg/L9rS3kNGvOvPV7fCXQ8hpktfOiWMZMjqTvGjAphPEhEvjo NI7gnCj+vuWYxgorcAxClaaqvOmVNZE70S1ksDzGGGxstpgV0E2qGkVAOxt1nziFZn1G 1O6xSLP//IUNvqfI9kOhn9IvLH5ldspb8ud8lh8eVKffyh178ISyxRXRAl+piWUhlYf4 ec4WE2eWe38lgQcUCZmCFOSaewM///zt0/O/MitGzFFFwm7uzf1euku1R7Ro7ATtG9UQ t9H7EAp5QVzp/i1a4X5ex/Yx6+BWsfqLTBzHKZTrzJDwE8KKgblrhvWLBB4iVmSVlVMV i4bA== X-Gm-Message-State: AOAM5307DYkuLaA7txKIDSTD976UQZqNEviIRmnW6WpADYpvFa2WsDXF GTFM+0bqHV2jSAGvY66tCrakXQ== X-Google-Smtp-Source: ABdhPJycrdUhyCSUHMiEl3AVoXNS8IU5MHQmc97vHR5mkiRNLWftK71zRHgJH8/e1k3HiVWQ63htXw== X-Received: by 2002:a05:6870:61c4:: with SMTP id b4mr3648778oah.322.1644816903115; Sun, 13 Feb 2022 21:35:03 -0800 (PST) Received: from ripple.attlocal.net (172-10-233-147.lightspeed.sntcca.sbcglobal.net. [172.10.233.147]) by smtp.gmail.com with ESMTPSA id y15sm12091337oof.37.2022.02.13.21.34.59 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 13 Feb 2022 21:35:01 -0800 (PST) Date: Sun, 13 Feb 2022 21:34:48 -0800 (PST) From: Hugh Dickins X-X-Sender: hugh@ripple.anvils To: Vlastimil Babka cc: Hugh Dickins , Andrew Morton , Michal Hocko , "Kirill A. Shutemov" , Matthew Wilcox , David Hildenbrand , Alistair Popple , Johannes Weiner , Rik van Riel , Suren Baghdasaryan , Yu Zhao , Greg Thelen , Shakeel Butt , linux-kernel@vger.kernel.org, linux-mm@kvack.org Subject: Re: [PATCH 11/13] mm/munlock: page migration needs mlock pagevec drained In-Reply-To: Message-ID: References: <8e4356d-9622-a7f0-b2c-f116b5f2efea@google.com> <90c8962-d188-8687-dc70-628293316343@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: 1E09E140006 X-Stat-Signature: 5nfwoe8dznmsfqf341gw7xr1fsry1qnn X-Rspam-User: Authentication-Results: imf09.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b="Av/BOZka"; spf=pass (imf09.hostedemail.com: domain of hughd@google.com designates 209.85.161.51 as permitted sender) smtp.mailfrom=hughd@google.com; dmarc=pass (policy=reject) header.from=google.com X-HE-Tag: 1644816903-964848 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 Fri, 11 Feb 2022, Vlastimil Babka wrote: > On 2/6/22 22:49, Hugh Dickins wrote: > > > > Any new pagevec runs the risk of adding a new way of stranding, and we > > might discover other corners where mlock_page_drain() or lru_add_drain() > > would now help. If the mlock pagevec raises doubts, we can easily add a > > sysctl to tune its length to 1, which reverts to synchronous operation. > > Not a fan of adding new sysctls like those as that just pushes the failure > of kernel devs to poor admins :) > The old pagevec usage deleted by patch 1 was limited to the naturally larger > munlock_vma_pages_range() operation. The new per-cpu based one is more > general, which obviously has its advantages, but then it might bring new > corner cases. > So if this turns out to be an big problem, I would rather go back to the > limited scenario pagevec than a sysctl? Okay, I'll delete that comment proposing a sysctl, which was more as a possible safety measure for our internal experimentation than for general use. I just thought it was an easy way to force synchronous. I don't expect a big problem. The flush in this commit deals, I think, with the only way it was treading on its own toes, using a pagevec at a level which relied on the unlikelihood of a pagevec reference. But I can imagine that such-and-such a test will expect Mlocked or Unevictable to be exact, and this pagevec now delay it becoming exact. I've not seen any example so far, but it does seem possible. Maybe we shall fix the test, maybe we shall add a drain. I hadn't thought of limiting the use of pagevec to the mass operation (if a significant problem emerges). Yes, that might be a better idea, thanks. Anyway, we don't need to worry in advance. A change I also had in this patch, orginally, was for /proc/sys/vm/stat_refresh to lru_add_drain_all() first. I'm surprised that tests see good numbers without it doing so; but since I've not actually seen the need for it yet, dropped that - we can always add it later if need emerges. Hugh