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 ADABCC5475B for ; Wed, 6 Mar 2024 04:34:05 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 1855F6B009D; Tue, 5 Mar 2024 23:34:05 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 135916B009E; Tue, 5 Mar 2024 23:34:05 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id F3EDD6B009F; Tue, 5 Mar 2024 23:34:04 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id E186D6B009D for ; Tue, 5 Mar 2024 23:34:04 -0500 (EST) Received: from smtpin17.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id B3DC4160AFC for ; Wed, 6 Mar 2024 04:34:04 +0000 (UTC) X-FDA: 81865346808.17.BE83984 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf07.hostedemail.com (Postfix) with ESMTP id 830AC40002 for ; Wed, 6 Mar 2024 04:34:02 +0000 (UTC) Authentication-Results: imf07.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=adOTAbWd; spf=none (imf07.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1709699643; 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=LYE7vpCiVzY5qyo/riJkpTvXpHju/QtifZPiMXSjOOY=; b=XXP6lTnqX2oyJpJVX0fi41S67FrNyBQGAvk2huIN4d2dSwu+6cIyZlrwVctMQC8gw8pVeF cAq4hIEvU8KcLlu47CfvHcfEduLaiJXseiVR9/mT3kb+UBU5E88Tkov3rnBHFUBIMoASvJ faO9lUsu/oAfMHRNwvN4Y44jOXUiMVY= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1709699643; a=rsa-sha256; cv=none; b=P1U4nHwD6UXm09FlE/oliPG/a9nRcHBumU2NN3KoA4lU7WvsWnQGx+VUWvJP+Kz6S26ULX t0q+rDopXHPE6zrKRlCYsAb0twnthu0gNHJ6/t2DeoNSkMDkk/qK7NhxwmLEkWKiLfnDZE K07Tkk2nIGQwgY5Nj/8sQWRw3CH4LeI= ARC-Authentication-Results: i=1; imf07.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=adOTAbWd; spf=none (imf07.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org; dmarc=none DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Transfer-Encoding: Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date: Sender:Reply-To:Content-ID:Content-Description; bh=LYE7vpCiVzY5qyo/riJkpTvXpHju/QtifZPiMXSjOOY=; b=adOTAbWdUeX2QJcIH26Nw8QHlQ kRH7FBKQ/xd6U+4sKC4IBupxwRzsIeNwoMzeA+lOW1+yVDzaXCmDGoJKsfxV6ksG8R9E1W5HaTmKK Crw4Eu9Q2W8A3b8y6HfOkJTeHCqmh3GVKaQVCd6WBRHT7FfMbFILbpHSRGDJE908iNPTAk+xZ5Emz Vp6eqkOGgDZlYWK0ugDvld9YN27vNMYbd1+Qu9wGn5HOPz0bRE9Pcqj0jr67G3PSn9Hel07wj+jkk lko6lASIfVXplcbIPqJDwmrwrjR4SiUEE7z+Uw4CWG7zvl7aisUpl6/6zETbY2YtXS+RMK9usIifL g0YBK5tw==; Received: from willy by casper.infradead.org with local (Exim 4.97.1 #2 (Red Hat Linux)) id 1rhiyZ-00000005zZY-2wQL; Wed, 06 Mar 2024 04:33:55 +0000 Date: Wed, 6 Mar 2024 04:33:55 +0000 From: Matthew Wilcox To: Yu Zhao Cc: lsf-pc@lists.linux-foundation.org, linux-mm@kvack.org, Jonathan Corbet Subject: Re: [Chapter One] THP zones: the use cases of policy zones Message-ID: References: <20240229183436.4110845-1-yuzhao@google.com> <20240229183436.4110845-2-yuzhao@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Stat-Signature: 33zbfsxqkzcnxwhd8dzytf9htm1kxygk X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: 830AC40002 X-Rspam-User: X-HE-Tag: 1709699642-700807 X-HE-Meta: U2FsdGVkX1845VlYiVqBE7t18qoVL7z7Cy2n2ozvyOIWNZQ+syfIFOcRODSTFjMIhlkixz4fOW3MOFrMtzpbep1kjCpGFiQuPSYWcLAb0pjS5Onh7LGaYdk1N3d7mXZ1yMyNqgBeobheGRLcZEa5nL8crTxfjnjnT87S42QsJecFwHX+4br6dIMYodnyKGlEfzFXXwfXySSDqF6x3qbYLopKLfnc099v4Tmc+N/7uPCIV0a4lzEGLWIvkn0EwjlPnNAZ8zyFp/DpzHyJl6RUfy8GGm5aqEm7qBolXIcMSsJ7OzK35PIbWNURuFxutMzUbrspH5AFnQuZVkTom2S623BL6W6fPbWw8YvJT7+Nqqbh+YhJISY42gl3OQZRkR0s8PEehwWwVzXN4VjCXalHUe6fl4mPL70Av8eaJKAyrCG5ZJx/+YyupseZuXiD65t+Gp+2X4RpJZpQ+Ije9K8sgskZNrsCIBtbhBWZjMlkmtq6XmEKc28p3ryspz9ZXbyMCouKdA+4hbJWuQVAGDAuhBz7z5/BfokkmrOBhCzBu7rKtVSSYcQnkeQk1qLmoLWtCRci78fQC1jR9dCk9kqE5Um+C9bGUHH7Hqh3/3b49jr7oadypBprqP7xitemE+/9YLo2HaZHUQbeXis1Hl5k9dHol0hwlRm6OPP+91nabkJL5+MNF6uXqKr+dQFLqM2EUZTbpqpWt6MvbL2Lo67U8nwgqypaVYDNDelMNGp7fhXuGH0k5RuJnznx/ffMjFv8Zu0cNOhXddiWa+tUitYs7t99LVWMoVtOjmHBygh1tHKwXg61g4VUrw6dn0SWU0eiRVHnN63fBJFvFmRSjwN2a+39qQLxxY+OOgKuWJJ5LeHZwHgRGcWwLewN2Ehkdh/M/A+YxlrY+85RkjNMU9mb3vMOULoFw/yz0N4QStz8iltk1dnTPzJJaATf/lxSoEwwWJ51+aCM2nEx2kwZZZM R/iI2E92 dovgAu2yxCkF8HqpcP1jhKxlz9G65SPYR6wL7hyhZKmD9itUvwygBPUtfehHmdbG7a4VVTZsz8O74eVyGIX5PzJPgrFO0i/FheNqOpBsc10lx2wtt85B126MzfFB9kiqj8B9/jgDR/QhA+jP3sZj1FJgXpgtsBlNzCClxu9duoCynxIiUSC1JeSTE4V+8pLbJZlTR X-Bogosity: Ham, tests=bogofilter, spamicity=0.000018, 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 Tue, Mar 05, 2024 at 10:51:20PM -0500, Yu Zhao wrote: > On Thu, Feb 29, 2024 at 3:28 PM 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. Right; the real question is what can we do to unify hugetlbfs and THPs. The reservation ability is one feature that hugetlbfs has over THP and removing that advantage gets us one step closer. > > 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. On a 32-bit system, we'll typically only have four; DMA, NORMAL, HIGHMEM and MOVABLE. DMA32 will be skipped since it would match NORMAL, and DEVICE is just not supported on 32-bit.