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.1 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A, SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 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 8F7EEC48BDF for ; Tue, 15 Jun 2021 07:41:44 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 0CE17610CD for ; Tue, 15 Jun 2021 07:41:43 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 0CE17610CD Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 8137A6B0036; Tue, 15 Jun 2021 03:41:43 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 79BED6B006E; Tue, 15 Jun 2021 03:41:43 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5EDE66B0070; Tue, 15 Jun 2021 03:41:43 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0054.hostedemail.com [216.40.44.54]) by kanga.kvack.org (Postfix) with ESMTP id 27CCE6B0036 for ; Tue, 15 Jun 2021 03:41:43 -0400 (EDT) Received: from smtpin26.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 8301FD203 for ; Tue, 15 Jun 2021 07:41:42 +0000 (UTC) X-FDA: 78255163644.26.85DB03E Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [216.205.24.124]) by imf21.hostedemail.com (Postfix) with ESMTP id EDAE8E000265 for ; Tue, 15 Jun 2021 07:41:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1623742901; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=eiWAWAfgpooQ2xl4pcC6APe1OHQBdi44nk+ZOpMt308=; b=KZgfjTfvyZGgwcohuVLlPbirVlw9p8mgmSvyzRuqgkmuFAT4NC+U1YNh0PDzToJm5f5DfZ U7lQ9V6I9+uXYoszSp9aboi9DAJhOSOn8d6nCfdxmNZGc7aaKJ2LoqpylDiOy8QpWcSBuC +himGBqTbe6Koxto2cdPKdv76y12loU= Received: from mail-wm1-f72.google.com (mail-wm1-f72.google.com [209.85.128.72]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-27-evucZsaaNHWdsx8KZAgCQQ-1; Tue, 15 Jun 2021 03:41:40 -0400 X-MC-Unique: evucZsaaNHWdsx8KZAgCQQ-1 Received: by mail-wm1-f72.google.com with SMTP id j2-20020a05600c1c02b02901cecbe55d49so110778wms.3 for ; Tue, 15 Jun 2021 00:41:39 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:cc:references:from:organization:subject :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=eiWAWAfgpooQ2xl4pcC6APe1OHQBdi44nk+ZOpMt308=; b=j/bQb3z1CRiIhmlPBAzfyPA8Un2Z3sohDrFmDLIFsgYgtf7tAMIrXwlg/liwU/ehd+ WjPqyEjm9cjZSzWOQZhpItN8GZCaVQDDkMIQJRBW37D6XdtWMOHnNMcIfErBawkFMEyF HWffAfTzCx3BY8/rhDDX2cP1goOZr9PgItCYEHham+Q66sMBUus/lgi4564bSK5KU/TH xhyEgL4fIaTiFB+eCxb2pxWcFZTGRtbMjoExhFw5Woovgw5dG5IKW6zFLKrTI0J64q9/ ESoYJfHbku/dNcicx53OpKq2b+ODJAIH5e/+EaGQrAw2rdd/ivKTY28jjCJKUbiIxTiF QBxw== X-Gm-Message-State: AOAM533yxsQbB93dMMcgJnRJ/280hRKJtb/pdxC2zWAwjhJxJoLsjLJX 1lbQBTFjR6kTYR4FaoMomPPqLLEs6VmDQooiXl1xsYTl8/gHF65YulD4Tb/hEsZnfm5oEXwQPkQ YDiFtSzvFTdA= X-Received: by 2002:a1c:3dc2:: with SMTP id k185mr3593180wma.15.1623742899093; Tue, 15 Jun 2021 00:41:39 -0700 (PDT) X-Google-Smtp-Source: ABdhPJz4dJUPCLIjrgDWgE3DXT9PfzJ484ezswuv19w097V01AJr0DyEFWjOkK5iukj/l3E9oldJQA== X-Received: by 2002:a1c:3dc2:: with SMTP id k185mr3593154wma.15.1623742898836; Tue, 15 Jun 2021 00:41:38 -0700 (PDT) Received: from [192.168.3.132] (p5b0c6136.dip0.t-ipconnect.de. [91.12.97.54]) by smtp.gmail.com with ESMTPSA id x3sm1478119wmj.30.2021.06.15.00.41.38 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 15 Jun 2021 00:41:38 -0700 (PDT) To: "Matthew Wilcox (Oracle)" , akpm@linuxfoundation.org Cc: linux-mm@kvack.org, Heiko Carstens , Rafael Aquini , Vlastimil Babka , Yu Zhao , Vladimir Davydov , kirill.shutemov@linux.intel.com, Andrea Arcangeli , Donald Dutile , Rafael Aquini References: <20210612000714.775825-1-willy@infradead.org> From: David Hildenbrand Organization: Red Hat Subject: Re: [PATCH] mm: Mark idle page tracking as BROKEN Message-ID: Date: Tue, 15 Jun 2021 09:41:37 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.10.1 MIME-Version: 1.0 In-Reply-To: <20210612000714.775825-1-willy@infradead.org> X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Authentication-Results: imf21.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=KZgfjTfv; dmarc=pass (policy=none) header.from=redhat.com; spf=none (imf21.hostedemail.com: domain of david@redhat.com has no SPF policy when checking 216.205.24.124) smtp.mailfrom=david@redhat.com X-Stat-Signature: 5ese7r36zcuhx1y6ayd69hnf5w7ux4g5 X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: EDAE8E000265 X-HE-Tag: 1623742889-413027 Content-Transfer-Encoding: quoted-printable 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 12.06.21 02:07, Matthew Wilcox (Oracle) wrote: I might be missing something important, so some questions/comments > In discussion with other MM developers around how idle page tracking > should be fixed for transparent huge pages, several expressed the opini= on > 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. 1. A link to that discussion would be nice. I am missing some important=20 details in this patch description. 2. "should be fixed for transparent huge pages" -- has it always been=20 like this or has the behavior changed at some point? Do the semantics,=20 and how the feature is getting used, clearly identify this case that=20 needs fixing as something that really has to be fixed? Or was it always=20 like that and actually expected to work like that ("semtantics")? For example, just like for softdirty tracking, an over-indication might=20 be just fine. More extreme, I think idle tracking can actually deal with=20 an under-indication, if it's actually used for minor performance=20 improvements (just like with DAEMON). Again, this should be clarified in=20 this patch description. Because I read "This information can be useful for estimating the=20 workload=E2=80=99s working set size, which, in turn, can be taken into ac= count=20 when configuring the workload parameters, setting memory cgroup limits,=20 or deciding where to place the workload within a compute cluster." --=20 which doesn't sound like it has to be 100% correct in all of the cases. And "Since the idle memory tracking feature is based on the memory=20 reclaimer logic, it only works with pages that are on an LRU list, other=20 pages are silently ignored. That means it will ignore a user memory page=20 if it is isolated, but since there are usually not many of them, it=20 should not affect the overall result noticeably. In order not to stall=20 scanning of the idle page bitmap, locked pages may be skipped too", so=20 there are already special cases to deal with. 3. I don't see how the "better mechanisms" can actually be used to=20 accomplish the same goal. You state "uffd", however, I don't see a way=20 to actually achieve the same goal using uffd. In MISSING mode, you would=20 have to zap/discard page content to get an access notification. in WP=20 mode you really cannot catch reads. >=20 > 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 follo= wed > suit, but I have been unable to find why RHEL enabled it. My fellow RH people tell me that we enabled in RHEL7 on customer demand=20 and consequently enabled it in RHEL8. To me it feels like we might be removing a feature that is working just=20 as expected because the semantics might not be 100% clear to everybody=20 involved. Of course, I might be wrong, that's why I'm asking. I'd actually vote for documenting what's happening, just like we do for=20 locked pages and !LRU pages ... unless there is really something heavily=20 broken. --=20 Thanks, David / dhildenb