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 8335EC0032E for ; Wed, 25 Oct 2023 19:12:06 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 08F7B8D0011; Wed, 25 Oct 2023 15:12:06 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 03F718D0001; Wed, 25 Oct 2023 15:12:05 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E23CA8D0011; Wed, 25 Oct 2023 15:12:05 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id D26458D0001 for ; Wed, 25 Oct 2023 15:12:05 -0400 (EDT) Received: from smtpin20.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id AB5DBC0460 for ; Wed, 25 Oct 2023 19:12:05 +0000 (UTC) X-FDA: 81384929010.20.76AB8AC Received: from mail-qt1-f170.google.com (mail-qt1-f170.google.com [209.85.160.170]) by imf05.hostedemail.com (Postfix) with ESMTP id AB893100013 for ; Wed, 25 Oct 2023 19:12:03 +0000 (UTC) Authentication-Results: imf05.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=t3e9TSUg; spf=pass (imf05.hostedemail.com: domain of yuzhao@google.com designates 209.85.160.170 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=1698261123; 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=MQsXRm/26AnMKfle1hOvoePNzv6mvpNR6kguNEXwq5g=; b=a6zcR75f+Lp43b4n6cK8EE53n/heousBOrNawFXfQ3mlJ1bntzSet/RpljjxHoMj+l1/Bs VTrwqZqB5QJITtqKJcOUD5cop0zyh1oqRrt3S5CuV2aqPqABL+YZw/bCnAhoD6ybHWFh+E vCDgBItZdE+/AAZ7cDBzS2upD+qSf/o= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1698261123; a=rsa-sha256; cv=none; b=oQlkMaRY+6XlCDROlG7mfNXKN/EsDRrV50+Ozwj8GPTAuUvQKEm+u8lUQjiTEcotQ4undC maxkkmLEjJVxk6UQ/OoODtNMrM5FI4aM3CRj09vnnDGbskGrnXnbRPmC5xU+Ro9am9Hm6J xUMfqCxwYryBAK1xkHcjPd/qvuvcahw= ARC-Authentication-Results: i=1; imf05.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=t3e9TSUg; spf=pass (imf05.hostedemail.com: domain of yuzhao@google.com designates 209.85.160.170 as permitted sender) smtp.mailfrom=yuzhao@google.com; dmarc=pass (policy=reject) header.from=google.com Received: by mail-qt1-f170.google.com with SMTP id d75a77b69052e-419b53acc11so51011cf.0 for ; Wed, 25 Oct 2023 12:12:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1698261123; x=1698865923; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=MQsXRm/26AnMKfle1hOvoePNzv6mvpNR6kguNEXwq5g=; b=t3e9TSUgVSbp54kPyIKbF66tMTsqWUkltyl7ZWwTJD4tp7K0U03PmrFESTyrzWQ291 Wr1NnhoUEqcM20uLtvPMV/0D13+pS5uwag24THSeABdikZymkVWc30BD86kUz3WXLEWt eIu4IdtXE2OrwbKRtQAWOi2HfGMGEiNiomOG/W2cRLHHD+VY0zMolzdE4nDGsef3d5bb BRaQZqmXazrQT9dxDnG3QmEE1sEsCH33RIU0nYJ1gpivWeXkmDYPisnqR+UrLKY8uTJC 3jKo7axJ2ubx5Y81P9hADwvCQJjGrdWxUOxDuJFV0VASTVpsquO5mnE/yi3I1EVBBuuZ 7fZw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1698261123; x=1698865923; 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:message-id:reply-to; bh=MQsXRm/26AnMKfle1hOvoePNzv6mvpNR6kguNEXwq5g=; b=Dkd8l+K5CEiJSe4DpFmlvXJBaDWb4HNuk6jwo+cTTo0fbNdyY0JRPBWQXQ9qITJuS+ 1L1a+Vyq4nKFE2AB9U2FRv4PHN5J4hFSj/8mj8YtC6d+gc+4q+kmGnk9wDor0EpK+1x7 qXKjd6WfLEXQcun/OrmU5pQtNtTK2MxH5BVeYpq2w2i9rMg4+fmyQw+1rMIAaL8ya1pl OYASgHa1Iqkg1anDfJI29nDy97HRUGiHvaVyrqAI6naEH+QzqTqDXQkyOAvFdqyxHOSc ZfTlaHjgo9d1MupvYmRPSapMkdxVOJNiKqSe4HmWRijK+wTQAom915v6baoSrcQFBEcV UyZQ== X-Gm-Message-State: AOJu0YzV02Gc7VTTNtedmQFevPfubWMZqzUGQkbJEshSkwUaCxDchmyg m4eheBGt4l/CEMVEiOZ6IfhGoKEf15XZF5+LiOQbrA== X-Google-Smtp-Source: AGHT+IG6KDiuxywIZwUVL3S8gGg9WWokTQZh8SEtNeM0/s7tsiam2k4ilI1Lup8w7V77HEhKysK+YikM3ctquirsU/o= X-Received: by 2002:ac8:7cad:0:b0:41e:2984:6dba with SMTP id z13-20020ac87cad000000b0041e29846dbamr257820qtv.3.1698261122754; Wed, 25 Oct 2023 12:12:02 -0700 (PDT) MIME-Version: 1.0 References: <20230929114421.3761121-1-ryan.roberts@arm.com> <6d89fdc9-ef55-d44e-bf12-fafff318aef8@redhat.com> In-Reply-To: From: Yu Zhao Date: Wed, 25 Oct 2023 13:11:24 -0600 Message-ID: Subject: Re: [PATCH v6 0/9] variable-order, large folios for anonymous memory To: David Hildenbrand , Ryan Roberts Cc: Andrew Morton , Matthew Wilcox , Yin Fengwei , Catalin Marinas , Anshuman Khandual , Yang Shi , "Huang, Ying" , Zi Yan , Luis Chamberlain , Itaru Kitayama , "Kirill A. Shutemov" , John Hubbard , David Rientjes , Vlastimil Babka , Hugh Dickins , linux-mm@kvack.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: AB893100013 X-Rspam-User: X-Stat-Signature: m19xhjf8mb867pcpqkaht9rzrajwapnc X-Rspamd-Server: rspam03 X-HE-Tag: 1698261123-300968 X-HE-Meta: U2FsdGVkX19mMEftszzt/IafT5cQ4SvkEK9NUfSaASChgJ74YuGsQUILmPAA2W1UgWdHGBBHmDKjQZZC+ADKuRmujyt173clRkb7sD004zF6i1X/I5oO8wpjuNZ7lBkzCgxBZ2OmZ+vxJ86KI4K1gQHkGXAXg22EJmTj2ay0xosfKHhuu6VYLvbUrfwYstjeOMFlME3IbOL0o5zO4MvBr2rD8eO+ySRiTLmdF92MxmxvV3PBJjgzZHJ8xPgdlehIsIqhMq/yBBIiqiCGBtxfx1Jen1RAfuwIiDXN0Z+/0MRMpdne+SFFjdGXGFII+mpZh0uJBKFIi5Or1PKwLjDzyT6p4uP0SgeI5s7U4txmMqzmEjj/FptaxYOB/CkOgthxVkVzH7bzeU7dWPogZGzQiKkDm/6x54z0aL8uOuNwqLO0dBMZVz0KseZRL1fpiZ82JWSxYWGhqQVy0aEPa2e0UdQN5KZ2PPzUqP10WfwPSMt34wV9fA4By0HDcB1qyoyxFpKRcyZx5WgC5Fl55PKmJEVrMI1yxbDep5uB2DM5+0dPeZ8wg+yet9Otw5A00oXb1F+BvKLNmllvoB9/iHhfpVApbhIVY2Hce1/rjsoWSRhR4wZDVsGXfB/91t/A5NXQktQ90tdIPE6iIOjcOYfPg8jot6WrUlSNDTlTguXPVJQWQc53Z5dDlANz6hnowsVdqQclL1TOqV2QL7PjWE2lwsvGqb59tkLhsgC9FCkRRcNCXvuZqmiWA1Na/lMK3cHI0coEFnOyKK9aNTBt5scMfVGm7Od57A79LlV1JQWeoy2DpGi88+PKzWEVUC9PQW5kfI7nLbCJadsQshhO6tp77Tt3c4UUfz0muwguLDpaqhGadf2WsHguTccC5/TlRadsKE7VkrzygUC5CmEmkryRolDTqNYhCYjxRVOHfYy6CrTpspHK3p6UcZP/5nQ5DRzL0TSaFZG22mo030KZYyV Hx5WmCG7 erj5ORFhhFj7DIRyhgYuJp9yYVCHm34Zi2ucDBkkBnzXC3z+AQTMswKqDALJ0Ey+t/7JRFZa3oTrqd9Br5feDiPeq/TGmQB9H31Ckgk16am5hMPAekbeeAFSYB2kv5P87MhAytnJkiQJltJNqdtGWd7tDoV0jruJ9gkJZr05ZMGxF7/+SbuZlV9qs87R2m3N3FMR5tdXQzNUZWmQbqQiO3Jt9DhISH8GDuY6xuwXGmCf4upqRuAwDEb31eY5EnPfV61oJyqrBZNME/iBL4osE0ZLpDDhWUt08OACF1Qn/GLo+cqIAw2ROrBuj+PfIbmbWmb2Yk4p3gKLkqGOAmKCdYB9APLekzCf3UKkl 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: List-Subscribe: List-Unsubscribe: On Wed, Oct 25, 2023 at 12:47=E2=80=AFPM David Hildenbrand wrote: > > On 25.10.23 18:24, Ryan Roberts wrote: > > On 20/10/2023 13:33, Ryan Roberts wrote: > >> On 06/10/2023 21:06, David Hildenbrand wrote: > >>> On 29.09.23 13:44, Ryan Roberts wrote: > >>>> Hi All, > >>> > >> > >> [...] > >> > >>>> NOTE: These changes should not be merged until the prerequisites are= complete. > >>>> These are in progress and tracked at [7]. > >>> > >>> We should probably list them here, and classify which one we see as s= trict a > >>> requirement, which ones might be an optimization. > >>> > >> > >> Bringing back the discussion of prerequistes to this thread following = the > >> discussion at the mm-alignment meeting on Wednesday. > >> > >> Slides, updated following discussion to reflect all the agreed items t= hat are > >> prerequisites and enhancements, are at [1]. > >> > >> I've taken a closer look at the situation with khugepaged, and can con= firm that > >> it does correctly collapse anon small-sized THP into PMD-sized THP. I = did notice > >> though, that one of the khugepaged selftests (collapse_max_ptes_none) = fails when > >> small-sized THP is enabled+always. So I've fixed that test up and will= add the > >> patch to the next version of my series. > >> > >> So I believe the khugepaged prerequisite can be marked as done. > >> > >> [1] > >> https://drive.google.com/file/d/1GnfYFpr7_c1kA41liRUW5YtCb8Cj18Ud/view= ?usp=3Dsharing&resourcekey=3D0-U1Mj3-RhLD1JV6EThpyPyA > > > > Hi All, > > Hi, > > I wanted to remind people in the THP cabal meeting, but that either > didn't happen or zoomed decided to not let me join :) > > > > > It's been a week since the mm alignment meeting discussion we had aroun= d > > prerequisites and the ABI. I haven't heard any further feedback on the = ABI > > proposal, so I'm going to be optimistic and assume that nobody has foun= d any > > fatal flaws in it :). > > After saying in the call probably 10 times that people should comment > here if there are reasonable alternatives worth discussing, call me > "optimistic" as well; but, it's only been a week and people might still > be thinking about this/ > > There were two things discussed in the call: > > * Yu brought up "lists" so we can have priorities. As briefly discussed > in the call, this (a) might not be needed right now in an initial > version; (b) the kernel might be able to handle that (or many cases) > automatically, TBD. Adding lists now would kind-of set the semantics > of that interface in stone. As you describe below, the approach > discussed here could easily be extended to cover priorities, if need > be. I want to expand on this: the argument that "if you could allocate a higher order you should use it" is too simplistic. There are many reasons in addition to the one above that we want to "fall back" to higher orders, e.g., those higher orders are not on PCP or from the local node. When we consider the sequence of orders to try, user preference is just one of the parameters to the cost function. The bottom line is that I think we should all agree that there needs to be a cost function down the road, whatever it looks like. Otherwise I don't know how we can make "auto" happen. > * Hugh raised the point that "bitmap of orders" could be replaced by > "added THP sizes", which really is "bitmap of orders" shifted to the > left. To configure 2 MiB + 64Kib, one would get "2097152 + 65536" =3D > "2162688" or in KiB "2112". Hm. I'm not a big fan of the "bitmap of orders" approach, because it doesn't address my concern above. > Both approaches would require single-option files like "enable_always", > "enable_madvise" ... which I don't particularly like, but who am I to jud= ge. > > > > > > Certainly, I think it held up to the potential future policies that Yu = Zhou > > cited on the call - the possibility of preferring a smaller size over a= bigger > > one, if the smaller size can be allocated without splitting a contiguou= s block. > > I think the suggestion of adding a per-size priority file would solve i= t. And in > > general because we have a per-size directory, that gives us lots of fle= xibility > > for growth. > > Jup, same opinion here. But again, I'm very happy to hear other > alternatives and why they are better. I'm not against David's proposal but I want to hear a lot more about "lots of flexibility for growth" before I'm fully convinced. Why do I need more convincing? When I brought up that we need to consider the priority of each order and the potential need to fall back to higher orders during the meeting, I got the impression people were surprised why we want to fall back to higher orders. TBH, I was surprised too that this possibility was never considered. I missed today's THP meeting too but I'll join next time and if anyone has more ideas on this, we can spend some time discussing it, especially on how LAF should cooperate with the page allocator to make better decisions.