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=-5.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, USER_AGENT_GIT 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 62FA1C48BDF for ; Tue, 15 Jun 2021 06:40:36 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id EBC71613FA for ; Tue, 15 Jun 2021 06:40:35 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org EBC71613FA 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 8310D6B0036; Tue, 15 Jun 2021 02:40:35 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 7E0ED6B006E; Tue, 15 Jun 2021 02:40:35 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 65A596B0070; Tue, 15 Jun 2021 02:40:35 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0100.hostedemail.com [216.40.44.100]) by kanga.kvack.org (Postfix) with ESMTP id 33D0B6B0036 for ; Tue, 15 Jun 2021 02:40:35 -0400 (EDT) Received: from smtpin14.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id C0D148249980 for ; Tue, 15 Jun 2021 06:40:34 +0000 (UTC) X-FDA: 78255009588.14.BE66236 Received: from mail-qk1-f174.google.com (mail-qk1-f174.google.com [209.85.222.174]) by imf04.hostedemail.com (Postfix) with ESMTP id A753536D for ; Tue, 15 Jun 2021 06:40:28 +0000 (UTC) Received: by mail-qk1-f174.google.com with SMTP id 5so2932229qkc.8 for ; Mon, 14 Jun 2021 23:40:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id:in-reply-to; bh=4NWLu/uaWrX/Zfh2oovnrPKa4YVetf4ADEc+XFxSK6E=; b=DiAgrId8bBZfDs0GTEAH4/CLTCYMUUNi3v8OZaJf8e4i+BgEb9LIVhX3VVZX+pnPqA 2r4LWQRVcqDIBU4WuKKS3nhLS8eGxRy2KF5JfF2xJrO2TPbirz5Fxl89eFhqQun9LVSC epNYUQ/zyVqIlO8ZInEiDz01l/Cb2GTartJy/vru8EMhNpy4VxWPxOf4YGjo0by1rHWm 08dhPxcWH22tMGtBnDO6moijcOGp4JvlzUgu7ATbuljcCeIQKyoaft5lT9vjOYkLOuRr S3u93LSlXP/Mpzy0eWU0z9UGcEPQJcvKPivXuotH084279I1foa3fXiVZcdbF0S8FaTH /0Xg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to; bh=4NWLu/uaWrX/Zfh2oovnrPKa4YVetf4ADEc+XFxSK6E=; b=R1mkFLREdUfqaZQsgeyQrvvsxBaAm5Pe881C7BJjwLRZIoH66uRo348bL/1AXaDvOr hOVct+JHMtcO3P6mZTOQJ0lOGPyTdEhJEA3mXA6rJZDpw2MVkRPe5qobgQp+HMzZLlwg nGlilQ6Hb2w1ZU+QgLSoudazQTe+KahEkLds9dhK3Xp0N/KK+lwaXbJVeRaYf3Ybm408 HgILY9qex2xU5Nilor4cbg4XM5gppC6cM0KETxcxY/hsnTVWA8cfVjKrnvVp2SOm8CIS MM2mQLEwFGBLkYu1UY7yPPJf5I4EbT2cycpMOMvNrvojzkGvUnF/2/rKCvmI/VziXU/T YbjQ== X-Gm-Message-State: AOAM531b7ljyh49FPpM95MVYgPTjz1rI5FK2WQOcdmBkAV/XemkNQiRs res9vzuWlLAoVmybX9w2iFw= X-Google-Smtp-Source: ABdhPJyaE3+12vf13yhm+Cs83P1t7UDSd+KfpJPy2m5HFw5JI330SAKtdKNXP6HnoxptMayl0pieFg== X-Received: by 2002:a37:a1d5:: with SMTP id k204mr20674584qke.300.1623739233748; Mon, 14 Jun 2021 23:40:33 -0700 (PDT) Received: from localhost.localdomain (ec2-35-169-212-159.compute-1.amazonaws.com. [35.169.212.159]) by smtp.gmail.com with ESMTPSA id v5sm11620967qkh.39.2021.06.14.23.40.33 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 14 Jun 2021 23:40:33 -0700 (PDT) From: SeongJae Park X-Google-Original-From: SeongJae Park To: Andrew Morton Cc: SeongJae Park , "Matthew Wilcox (Oracle)" , akpm@linuxfoundation.org, linux-mm@kvack.org, Heiko Carstens , Rafael Aquini , Vlastimil Babka , Yu Zhao , Vladimir Davydov , kirill.shutemov@linux.intel.com, amit@kernel.org, sjpark@amazon.de Subject: Re: [PATCH] mm: Mark idle page tracking as BROKEN Date: Tue, 15 Jun 2021 06:40:28 +0000 Message-Id: <20210615064028.18813-1-sjpark@amazon.de> X-Mailer: git-send-email 2.17.1 In-Reply-To: <20210614190420.af6bb3ca193541cdb606517d@linux-foundation.org> Authentication-Results: imf04.hostedemail.com; dkim=pass header.d=gmail.com header.s=20161025 header.b=DiAgrId8; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf04.hostedemail.com: domain of sj38park@gmail.com designates 209.85.222.174 as permitted sender) smtp.mailfrom=sj38park@gmail.com X-Rspamd-Server: rspam02 X-Stat-Signature: 8nj3poq3gnw49qgbh9sc8n53ss7hnbwh X-Rspamd-Queue-Id: A753536D X-HE-Tag: 1623739228-127028 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: From: SeongJae Park On Mon, 14 Jun 2021 19:04:20 -0700 Andrew Morton wrote: > On Mon, 14 Jun 2021 13:49:26 +0000 SeongJae Park wrote: > > > From: SeongJae Park > > > > Hello Matthew, > > > > On Sat, 12 Jun 2021 01:07:14 +0100 "Matthew Wilcox (Oracle)" wrote: > > > > > In discussion with other MM developers around how idle page tracking > > > should be fixed for transparent huge pages, several expressed the opinion > > > that it should be removed as it is inefficient at accomplishing the > > > job that it is supposed to, and we have better mechanisms (eg uffd) for > > > accomplishing the same goals these days. > > > > I think the THP case[1] is an intended behavior[2]. Could you please share a > > link to the discussion or a detailed summary if possible? > > > > > > > > Mark the feature as BROKEN for now and we can remove it entirely in a > > > few months if nobody complains. It is not enabled by Android, ChromeOS, > > > Debian, Fedora or SUSE. Red Hat enabled it with RHEL-8.1 and UEK followed > > > suit, but I have been unable to find why RHEL enabled it. > > > > Amazon Linux is also using it[3], for DAMON[4]. In detail, DAMON doesn't use > > Idle Page Tracking but PG_Idle in kernel space, to avoid interfering the > > reclaim logic[5]. So, I'm ok with removing the Idle Page Tracking user space > > interface, but gonna be opposed to removing PG_Idle. > > > > Nevertheless, the interference is not a real problem to DAMON, as DAMON is > > aimed to provide just a reasonable quality of the monitoring, rather than > > strict correctness. Hence, if people think the interference is also not a > > problem for the reclaim logic (after all, it does nothing unless sysadmin > > manually turns it on in runtime, and can be turned off at anytime), I would > > simply update DAMON code to don't use PG_Idle, add warnings in the doc, and > > wouldn't be opposed to this change. > > Couldn't the DAMON patchset simply re-add PG_Idle? Perhaps with a new > name which is more appropriate to the DAMON usage? Good point, that makes sense. Thank you, Andrew. Nevertheless, I still not fully understand why Idle Page Tracking is considered broken, and therefore worrying if I will end up reintroducing PG_Idle with DAMON patchset in the broken form. It would still be great if a link to the dicussion could be provided. Thanks, SeongJae Park