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 4C390C54E49 for ; Wed, 6 Mar 2024 03:52:03 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id D74736B0081; Tue, 5 Mar 2024 22:52:02 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id D24F76B0082; Tue, 5 Mar 2024 22:52:02 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id BED2E6B0083; Tue, 5 Mar 2024 22:52:02 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id AE2F76B0081 for ; Tue, 5 Mar 2024 22:52:02 -0500 (EST) Received: from smtpin11.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 75C40140D45 for ; Wed, 6 Mar 2024 03:52:02 +0000 (UTC) X-FDA: 81865240884.11.D90542F Received: from mail-ed1-f43.google.com (mail-ed1-f43.google.com [209.85.208.43]) by imf05.hostedemail.com (Postfix) with ESMTP id 9BF71100010 for ; Wed, 6 Mar 2024 03:52:00 +0000 (UTC) Authentication-Results: imf05.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=WvyK35gj; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf05.hostedemail.com: domain of yuzhao@google.com designates 209.85.208.43 as permitted sender) smtp.mailfrom=yuzhao@google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1709697120; 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=fnFyy0IGL5QzM9YXN9g3IAOa2IUeQUvaB3kJgjyfxIc=; b=PPC98XvXg/kDRV9thf11t51Nnsh8ik0Dpk+lj5lvz57wxa6cw9nPHAiotLzJwDZljDne6R kTOQX6NuEXefDlrrhD/7tQoxdeYN1xHVyhlknZnUeSZE3yJw/9hvjzaUkWob/ByBTNPAqt KZplhFtdN34flPNzhmNj+KwOhrGHqbU= ARC-Authentication-Results: i=1; imf05.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=WvyK35gj; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf05.hostedemail.com: domain of yuzhao@google.com designates 209.85.208.43 as permitted sender) smtp.mailfrom=yuzhao@google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1709697120; a=rsa-sha256; cv=none; b=xPEQeeUdDVCVDk26MwrKf/jegdE68rJLFs4pf95+7IuGy8BWsvDGky4NqX/Wr1WELfjlvi B8qJnaghhDQ2p/pAaBmfWZ+DRE+RI6LkBROk+2zW4xTiWn+KRbNF3kJDI3ijQ+04+LL/kG /mfL6frb6Q/exyVnrLC076Q4Vi4zZmA= Received: by mail-ed1-f43.google.com with SMTP id 4fb4d7f45d1cf-5654ef0c61fso8025a12.0 for ; Tue, 05 Mar 2024 19:52:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1709697119; x=1710301919; 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=fnFyy0IGL5QzM9YXN9g3IAOa2IUeQUvaB3kJgjyfxIc=; b=WvyK35gjR32LuxZAi6LPCWNGA6Oo/fnmCcykmzMOcpZl0l2G5Hfn1SLmdqBB7K7c7j hjVijCEoeHfwEt2mt2t2CSxhygvIzpSwB5lXBYfH+tAOMpHsWoPSom31LiQNxnsnWzlz bKy9r6XO6UOJFxyacKgPd5J4+pr7Y88z2SaIQqpTJ9ZgddtWM1t/jshfe5G30TcGejt9 XF8UVaw9tjjuYtjfOMzmSvUG7quZrlbsh+smGadh40FhgLGuxn02BTgmBEFMW8WvJxKO PfqTPgltm408iXEO6Au/nlPQ0YX7dfX/ahzT2YUkd6TPkbUkdGvSz1MhAI/sT4l5r/Y7 GaQA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709697119; x=1710301919; 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=fnFyy0IGL5QzM9YXN9g3IAOa2IUeQUvaB3kJgjyfxIc=; b=Hnfgm44iy50T/vAI3JXvLJjaW8JfuESg7M9G5W37YThqQNRpi96nK7OZ7AD4XahyEU a1oswNxcXBcd+VafOefYVEe/1U31wuKUgR6cCLGyKhVtfMPZveF7lvDVVtr8Yoh8pYtl CrLSbHcza/MspQ/dRQkmRWQy7J4kLOD5+lEniTfAt2jurwHxqdxgqESSrlx9n9pYuzox yjbAPTc0musNLvCEn989R/NH61JXuV2c7d7gpBBZDjNH1qPTv8pqGlecHEePpUL04Cru 5riItj6htZ3wCN9MROv9NTbUgoeVQr9McwnGtB+8ZMF0PQHaGmkYHkpOE/7vIXQPfFdJ kkAg== X-Forwarded-Encrypted: i=1; AJvYcCXkBa/w1st0cpD3V/4oTrWcjXs5ZkQ8ZiBN4eknuWS5NrpwuyG/wQeCaLCHyr6d5D10Ng+FYnl5O42QG9D2vlYbaPs= X-Gm-Message-State: AOJu0YxKUI1m1PX0wohZCdk7RSXvVOM7YsVWWyUvMarGAhbVTZfFrKSv jDrh0WhIteirC7WiXBQrSdAYgJ8xeNearRrYi/ojoa6DaDBmD/liV1NeE0svxU3JkQu+WrFEGJu lnYfSdgoufPnRMY6yI/5X8MrqxHS/h3deelPA X-Google-Smtp-Source: AGHT+IGG3plWBzFbytxRY6q/SqfumSDcG5xRnAtftEchaIPwZwDJQlhDLazHCNwlzu6uDaZrv9mFGAQtq/IGJFuOdoM= X-Received: by 2002:a05:6402:695:b0:55f:8851:d03b with SMTP id f21-20020a056402069500b0055f8851d03bmr277058edy.5.1709697118951; Tue, 05 Mar 2024 19:51:58 -0800 (PST) MIME-Version: 1.0 References: <20240229183436.4110845-1-yuzhao@google.com> <20240229183436.4110845-2-yuzhao@google.com> In-Reply-To: From: Yu Zhao Date: Tue, 5 Mar 2024 22:51:20 -0500 Message-ID: Subject: Re: [Chapter One] THP zones: the use cases of policy zones To: Matthew Wilcox Cc: lsf-pc@lists.linux-foundation.org, linux-mm@kvack.org, Jonathan Corbet Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Stat-Signature: 1kgeepf68koufwmrtn86z7ff3cftxyms X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: 9BF71100010 X-HE-Tag: 1709697120-977818 X-HE-Meta: U2FsdGVkX1/8IFIhc8DJagiOUbi3UZ49yYlHxnvbX07/4MmX/1sN7gXt1qMIbjZdMeQDHCIEK6pnVK0NU2r6sIA4ecqaQUPpgKbf08AOdO9WMD4Ha6/7uM6dxeCipUa21Gjwv04QSKhLPLhiwU8i5DdJiItXjmgBmxsmm2CcN0DNsmK4+nlDHEYhh4n+yesfwCZ5QLrstKq5CkLto1GSmC78gNWf7wxGw0JFKix4TtCOpDEOVp9seL4ODK3SorTQ3/xLEw0581WMAxbw0Sn3W2SSmh1MtDJ0476CxchdSvsTl8OttY3ZPmYHmM0roXvJfQDHcKxOidvOZUj0qP+8Z5rIGh1CPKg32V40U8xNUQxbs9s71TmmQ6veD9w8SXFkh9lp+XXmkq0pMwDSF+dQPCQsJVX2SOgGqBXDl6T+hM5qAgqqkRD5fcvyQ/hkA41A/+t2yIezpJgBVT9MdyhHIAVJr4frxqMXXySvlzyxwJgTWPU5MZy6EWDouPNDafrQto7JEBBW70jwtQaoW98i3lqAvSlcL8fVFlvLoeXq6ABaYV9LK1zKFqg1mv5UlBDOGqKI2SGAvCjRTktHpf9XYMK499a/sDIfol3T2mr0Wzs7o5dnSzTGy5qt6xL+JZJnrQ6UPzjpQArX7XyAOAl/RmkY43/YCeWsq/TLEX2OrxFeI9YgyP9/QUg+5BIrsoea4dyygXI8I/NzJ58qf87xeu8oVPgb6gb5bz7wPnVX0HHPIZZmc9fcO67kmHeKmWuRpKTLYe78VgF9DEv+u2UXBjvlzHLnI1YaIysnaHr0DOFxcEsj8/lYLyaobflOGnOvRUvpwaKzjuTmmVeGK4IcWXu2ah9ePGtutlNaGH6ggfdNrilEd+Mp0hYHqxFtiVTeSktcg8PLAwo5qPu88sFacFBiWf/sbGH6Q9hCyjz04V8E0JiNPoh86VB2/YdV9ffzfEFr6psmhKxKHb9AkQw r/RRgKCu VTfoljPb+B4yX9GkxDRiL2lHPJUMzMGdzCPBABiIHCK/I3Z4FwpwluexIAQwAGNG+9Lfy9damLSJ1caXe9KzUbO+ImIuqwWyKkrRam4xGCtrXJutWuv+J55Y5cjoyJvQ//D/nQpkCdKQUEF+mSUUBwPE7j+QDNwsUhK3X8EOJUFDY04PF6HYHXj2SceT56oxsNPqsTl0R8mmjhQmwTLmbp04siu1TUzj5GDyiSqOJyyaCA1jBVHcdkHEYagTJGIQdBHPFDp2Ap7mrklBooTwrj96DaTUuk56eGAcZ X-Bogosity: Ham, tests=bogofilter, spamicity=0.000033, 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 Thu, Feb 29, 2024 at 3:28=E2=80=AFPM Matthew Wilcox wrote: > > On Thu, Feb 29, 2024 at 11:34:33AM -0700, Yu Zhao wrote: > > Compared with the hugeTLB pool approach, THP zones tap into core MM > > features including: > > 1. THP allocations can fall back to the lower zones, which can have > > higher latency but still succeed. > > 2. THPs can be either shattered (see Chapter Two) if partially > > unmapped or reclaimed if becoming cold. > > 3. THP orders can be much smaller than the PMD/PUD orders, e.g., 64KB > > contiguous PTEs on arm64 [1], which are more suitable for client > > workloads. > > Can this mechanism be used to fully replace the hugetlb pool approach? > That would be a major selling point. It kind of feels like it should, > but I am insufficiently expert to be certain. This depends on the return value from htlb_alloc_mask(): if it's GFP_HIGHUSER_MOVABLE, then yes (i.e., 2MB hugeTLB folios on x86). Hypothetically, if users can have THPs as reliable as hugeTLB can offer, wouldn't most users want to go with the former since it's more flexible? E.g., core MM features like split (shattering) and reclaim in addition to HVO. > I'll read over the patches sometime soon. There's a lot to go through. > Something I didn't see in the cover letter or commit messages was any > discussion of page->flags and how many bits we use for ZONE (particularly > on 32-bit). Perhaps I'll discover the answer to that as I read. There may be corner cases because of how different architectures use page->flags, but in general, this shouldn't be a big problem because we can have 6 zones (at most) before this series, and after this series, we can have 8 (at most). IOW, we need 3 bits regardless, in order to all existing zones.