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 D594FC38145 for ; Fri, 2 Sep 2022 01:18:04 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 6F7338008F; Thu, 1 Sep 2022 21:18:04 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 6A59E8008D; Thu, 1 Sep 2022 21:18:04 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 56E1B8008F; Thu, 1 Sep 2022 21:18:04 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 4764B8008D for ; Thu, 1 Sep 2022 21:18:04 -0400 (EDT) Received: from smtpin04.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 1E1AD160762 for ; Fri, 2 Sep 2022 01:18:04 +0000 (UTC) X-FDA: 79865384088.04.669CBC3 Received: from mail-vs1-f52.google.com (mail-vs1-f52.google.com [209.85.217.52]) by imf12.hostedemail.com (Postfix) with ESMTP id CE3C340056 for ; Fri, 2 Sep 2022 01:18:03 +0000 (UTC) Received: by mail-vs1-f52.google.com with SMTP id o123so655110vsc.3 for ; Thu, 01 Sep 2022 18:18:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date; bh=rTzDP//vpfHx0nVWxJbV0HFrI6D0C5HQYNSPKTmQmqc=; b=UWgThLj5qQy1WVf4h5Ch3hkbBGqp3/CtfM0uY0BEiBrEmfKmoOMhR9TKodXHXQ8UZI Nps5eH9fwSuxS1+/Kpa/4rK/MRM5r5tRDduhRCq8fKqe8yv0MTE5YWK6lJZr7U3Jolcb 8ZeQtzQywmft38Mjk6K0YLw6peWxrRLhr7EWznpYO3b4hO0iexzPpulNjFSfTQZxKspw XpfMEuCDg7sCgaYl9UdRJUa36ssv+biiXphvOPD6fo0JdXpQUVd4pLJ0Y4/SyNJhRTHC j9MbKYChOijhjoCVpKNC/fLAUPWifHdbz2EqRZrbosyYkPYxfMGuUMyUiKg+WkmZWK4Y tBPg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date; bh=rTzDP//vpfHx0nVWxJbV0HFrI6D0C5HQYNSPKTmQmqc=; b=qUPbTpjCFfuW7SFu0YeZXxotI5IOn1KWjXXQHnGBERsuyYSviyL2MAJthdyAxr6E08 20dWPsCAm7Pejd1JrG5l+JEHRaTQfIcizo09vYqFX1TR6AtFF2KCNBRvaLz8LlTkAhYE ovCreSXx2VJw25O3aXzfnuXVXFUOBpSk7jzShbzsIeRtyOMGZVh7Rus8k62qInGfeDlU lk2V8ZMXBqkWIh1ZpVtxE8NBU1/HYfcOu2gd9auerfp/s5OffKEcChfiwgKbuHgFBLfF 0JVzXqN5YHTubQO06+TFek42GSZfpxeuXVkgbVKQXZEU3FzLGTKrYK0/tYicO4pmAra3 RFyA== X-Gm-Message-State: ACgBeo1lJD4oP2l8g9s8Kv07dMbKJPqt6LQg3Kf46wd2dojygVgrdYDu S2FrMGL02qA8AqVLfHz2b1uZSqnkIsN2DDpMg5Ghfg== X-Google-Smtp-Source: AA6agR7Tip6gCheFWRsDQxtd28hkc6ZUgXtTAsFe4eAmn5ExZQLdjvj3BoPN4Q/OdMBoJts2UxkQZmxs+NLu6F9s1wI= X-Received: by 2002:a67:d512:0:b0:390:db32:a96 with SMTP id l18-20020a67d512000000b00390db320a96mr8270856vsj.15.1662081482992; Thu, 01 Sep 2022 18:18:02 -0700 (PDT) MIME-Version: 1.0 References: <20220815071332.627393-1-yuzhao@google.com> <20220815071332.627393-8-yuzhao@google.com> <0F7CF2A7-F671-4196-B8FD-F35E9556391B@gmail.com> In-Reply-To: <0F7CF2A7-F671-4196-B8FD-F35E9556391B@gmail.com> From: Yu Zhao Date: Thu, 1 Sep 2022 19:17:26 -0600 Message-ID: Subject: Re: [PATCH v14 07/14] mm: multi-gen LRU: exploit locality in rmap To: Nadav Amit Cc: Andrew Morton , Andi Kleen , Aneesh Kumar , Catalin Marinas , Dave Hansen , Hillf Danton , Jens Axboe , Johannes Weiner , Jonathan Corbet , Linus Torvalds , Matthew Wilcox , Mel Gorman , Michael Larabel , Michal Hocko , Mike Rapoport , Peter Zijlstra , Tejun Heo , Vlastimil Babka , Will Deacon , Linux ARM , "open list:DOCUMENTATION" , LKML , Linux MM , X86 ML , Kernel Page Reclaim v2 , Barry Song , Brian Geffon , Jan Alexander Steffens , Oleksandr Natalenko , Steven Barrett , Suleiman Souhlal , Daniel Byrne , Donald Carr , =?UTF-8?Q?Holger_Hoffst=C3=A4tte?= , Konstantin Kharlamov , Shuang Zhai , Sofia Trinh , Vaibhav Jain Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1662081483; a=rsa-sha256; cv=none; b=A3NJW4UkGjxBmRywLQum3Kd4Xaj2ZGndzJBs9tmFfOrgwfx21wVjXeB9NoKlvYibu8XL6J dHyl37KJZqTE1mMEe6UeaHJQH58GEeyXv1dtfc8pFbqG5aEm/7VL0WXAn+T8ZefQRqAjYC fzaZcpzceCfw3eEQF6x9U7LCwKVZUFI= ARC-Authentication-Results: i=1; imf12.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=UWgThLj5; spf=pass (imf12.hostedemail.com: domain of yuzhao@google.com designates 209.85.217.52 as permitted sender) smtp.mailfrom=yuzhao@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1662081483; h=from:from:sender: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:dkim-signature; bh=rTzDP//vpfHx0nVWxJbV0HFrI6D0C5HQYNSPKTmQmqc=; b=XfGo5eF96InjdFCB9SYH2YcZUa/cLJr54xQCkV+LFdPhvxM59VjEVNRVP6Dbx0bq4oQcVd 5eXsTplEU9Et6WFynDCB3Tze4kY2IgSv46F1K1Rdqvp0vQpMqeCJIL9idLKFN5FkPoUcnW C9Z6iRBt2A2dui30iJ3tfPGO3di//Po= Authentication-Results: imf12.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=UWgThLj5; spf=pass (imf12.hostedemail.com: domain of yuzhao@google.com designates 209.85.217.52 as permitted sender) smtp.mailfrom=yuzhao@google.com; dmarc=pass (policy=reject) header.from=google.com X-Stat-Signature: nehef8nnkkeczmshmcdmd1jphohmsnxp X-Rspamd-Queue-Id: CE3C340056 X-Rspamd-Server: rspam04 X-Rspam-User: X-HE-Tag: 1662081483-591274 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 Thu, Sep 1, 2022 at 3:18 AM Nadav Amit wrote: > > > > > On Aug 15, 2022, at 12:13 AM, Yu Zhao wrote: > > > > Searching the rmap for PTEs mapping each page on an LRU list (to test > > and clear the accessed bit) can be expensive because pages from > > different VMAs (PA space) are not cache friendly to the rmap (VA > > space). For workloads mostly using mapped pages, searching the rmap > > can incur the highest CPU cost in the reclaim path. > > Impressive work. Sorry if my feedback is not timely. > > Just one minor point for thought, that can be left for a later cleanup. > > > > > + for (i =3D 0, addr =3D start; addr !=3D end; i++, addr +=3D PAGE_= SIZE) { > > + unsigned long pfn; > > + > > + pfn =3D get_pte_pfn(pte[i], pvmw->vma, addr); > > + if (pfn =3D=3D -1) > > + continue; > > + > > + if (!pte_young(pte[i])) > > + continue; > > + > > + folio =3D get_pfn_folio(pfn, memcg, pgdat); > > + if (!folio) > > + continue; > > + > > + if (!ptep_test_and_clear_young(pvmw->vma, addr, pte + i)) > > + continue; > > + > > You have already checked that the PTE is old (not young) so this check > seems redundant. You are right, for x86, which belongs to category 1: hardware and OS share the same paging data structure. > I do not see a way in which the access-bit can be cleared > since you hold the ptl. There is also category 2: the OS paging data structure is a shadow of what hardware actually uses, e.g., POWER9 radix. To make both categories work, the general rule is that the OS paging data structure must be more strict, i.e., it can have A/D bits set while the hardware paging data structure may not. The opposite is not allowed, even for the A bit, because the A bit can also be used to determine whether a TLB flush is required. The Linux kernel doesn't do this but there are other OSes that do. For prefaulted PTEs, we generally mark them young unless arch_wants_old_prefaulted_pte() returns true (currently only ARMv8.2+ do). On POWER9, we'd see those PTEs pass the first check but fail the second. > IOW, there is no need for the =E2=80=9Cif" and =E2=80=9Ccontinue". > > Makes me also wonder whether having a separate ptep_clear_young() can > slightly help, since anyhow the access-bit is more of an estimation, > and having a separate ptep_clear_young() can enable optimizations. > > On x86, for instance, if the PTE is dirty, we may be able to clear the > access-bit without an atomic operation, which should be faster. Agreed.