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=-13.3 required=3.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_IN_DEF_DKIM_WL autolearn=no 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 9AE3AC48BE5 for ; Wed, 16 Jun 2021 19:23:37 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 18F606128B for ; Wed, 16 Jun 2021 19:23:36 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 18F606128B Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=google.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 5F9BF6B0036; Wed, 16 Jun 2021 15:23:36 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 5852A6B006C; Wed, 16 Jun 2021 15:23:36 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3FC556B0070; Wed, 16 Jun 2021 15:23:36 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0067.hostedemail.com [216.40.44.67]) by kanga.kvack.org (Postfix) with ESMTP id 099DE6B0036 for ; Wed, 16 Jun 2021 15:23:35 -0400 (EDT) Received: from smtpin40.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 8FB1E8415 for ; Wed, 16 Jun 2021 19:23:35 +0000 (UTC) X-FDA: 78260561190.40.72050CE Received: from mail-wr1-f50.google.com (mail-wr1-f50.google.com [209.85.221.50]) by imf26.hostedemail.com (Postfix) with ESMTP id 316F440002C1 for ; Wed, 16 Jun 2021 19:23:29 +0000 (UTC) Received: by mail-wr1-f50.google.com with SMTP id d11so1524094wrm.0 for ; Wed, 16 Jun 2021 12:23:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ezZP78GYiYW9WTw1y1DnzUXYaeonJgjvtduPLd4pOkM=; b=CVWOLWam+G9uvE0quI41ND0Yo/pec7Jrud53fjZKwomIHOgjuwhgcLpvtxppc/XXW8 dib4L0RKtBUtbAPtkjXdD8/jRB17vDmJrZJN0FF7mZb8J4lO6JzwJ1yizcJ7tBnJOyT4 UT2bQDGkqyxajtvgSHs/O06YAs4rHwBbZ78Qoyb5+ftIy6H1lDeA1soeefZAwNIOIqh5 /uQVnEDffPUH+y3cjdbNIRxiQGNfDU5wVg6p0Ip22lSEaDggapsIaLTC1teYvkaw0xKO HE/dIyUvDaaFA+O1c3KqbvbXBMfjQ2hA72EXdkvoCcFkcARVrEvKpZ39+lMw8QxU6ASZ 9/tA== 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=ezZP78GYiYW9WTw1y1DnzUXYaeonJgjvtduPLd4pOkM=; b=l1c8ymhur6iGh25zJiVPsUUE7cUWW+yDmtnqrQV2ngXJFlOuoatHJALqg4uAkc1z9k HRxpS+5ro1n3sGb9O3NAF7RzJGArW+1GkPo6K2Dd4JkG1YVSYUCwgYVjte44n40XIbhJ tatTU95Ff0Kp0RfUiNwlDRQA+OBFZXXjJvsp4V+pdlV5Hwnh9dINjHmzW5YPwB8sLnYG l+/tw+Jz6EXlgDC00pM3GHwAWRnqEiJZsdFd7dEuXqwu8ParS06YBHwlFanGks0zYC2C 6V/kGFUGfY8iWCXvnh60nA97ha/Lvxts4nFZJzdSKec7xXtaPI6z8ynXTbd1tbUNIoqz YTaA== X-Gm-Message-State: AOAM532ruFuq3bWDJfZ7pgCFFJFe2fU7D/1vwUL4hHpq0x4FdRWI6ZIc XDoy65MGOeQK4F2yaVKv4oW+IfShp5a74lqHpG1Wpw== X-Google-Smtp-Source: ABdhPJw7DcaZ6h722bE6HmOW/e8/7K7CZuFfjx68+F3Ak34JhPnCZ1VZz1hvlEmQSNCTZ+BPssFhacECgrIfA+511pg= X-Received: by 2002:a5d:44d2:: with SMTP id z18mr762172wrr.358.1623871413829; Wed, 16 Jun 2021 12:23:33 -0700 (PDT) MIME-Version: 1.0 References: <20210612000714.775825-1-willy@infradead.org> <7b35885b-1413-5e08-3930-c8c4b66bcfe7@redhat.com> In-Reply-To: <7b35885b-1413-5e08-3930-c8c4b66bcfe7@redhat.com> From: Yu Zhao Date: Wed, 16 Jun 2021 13:23:22 -0600 Message-ID: Subject: Re: [PATCH] mm: Mark idle page tracking as BROKEN To: David Hildenbrand Cc: Vlastimil Babka , akpm@linuxfoundation.org, Linux-MM , Heiko Carstens , Rafael Aquini , Vladimir Davydov , "Kirill A . Shutemov" , Andrea Arcangeli , Donald Dutile , Matthew Wilcox Content-Type: text/plain; charset="UTF-8" X-Rspamd-Server: rspam01 X-Rspamd-Queue-Id: 316F440002C1 Authentication-Results: imf26.hostedemail.com; dkim=pass header.d=google.com header.s=20161025 header.b=CVWOLWam; spf=pass (imf26.hostedemail.com: domain of yuzhao@google.com designates 209.85.221.50 as permitted sender) smtp.mailfrom=yuzhao@google.com; dmarc=pass (policy=reject) header.from=google.com X-Stat-Signature: nspfkr9ruc8cpxszstnmncdtb5bma9yp X-HE-Tag: 1623871409-977778 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000221, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Wed, Jun 16, 2021 at 2:43 AM David Hildenbrand wrote: > > On 16.06.21 10:36, Vlastimil Babka wrote: > > On 6/16/21 8:22 AM, Yu Zhao wrote: > >> On Tue, Jun 15, 2021 at 8:55 PM Matthew Wilcox wrote: > >>> > >>> > >>> I don't know. I asked the others on the call and the answer I got was > >>> essentially "Just delete it". > >>> > >>> I'm kind of hoping the others speak up. > >> > >> I listed a couple of things when acking this patch. Being broken is > >> not a problem as long as there are users who care about it. What made > >> me think such users may not exist is that nobody ever complained about > >> those things until we stumbled on them -- I'm not insisting on > >> deleting this feature, just clarifying why I thought so. > > > > Similar feelings here. On the call it looked like the feature was abandoned by > > its creators, and it wasn't clear if the distros that had it enabled did so due > > to reasons that still apply for future versions. Sending the proposal and > > getting a feedback that there are users is one of the expected valid outcomes. > > For us (RH) it will be very interesting to know the exact things that > are "suboptimal" (I'm avoiding the terminology "broken" here), so we can > actually evaluate if this might affect customers and might be worth > "improving". I consider the examples I gave in my first email breakages -- others broke/break the idle page tracking -- and I think it's safe to assume they will continue to happen. If you are really looking for improvements, the page compaction has always been a good example. For the idle page tracking, with physical memory as little as 4GB, it needs to go thru one million PFNs, no matter how many compound or buddy pages there are. For THPs, it will try to get_page_unless_zero() on tail pages, which always fails. This is why we discussed it in the meeting. What can't be improved is the memory locality of PFNs. They are not grouped by memcgs or processes. Two PFNs next to each other can be from two processes with two sets of five-level page tables. The cache misses simply outweigh any potential benefits one might get from this feature, speaking as one of the customers.