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 766E7C25B75 for ; Wed, 29 May 2024 10:23:30 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id EACF06B00AE; Wed, 29 May 2024 06:23:29 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id E5C366B00AF; Wed, 29 May 2024 06:23:29 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D23FB6B00B0; Wed, 29 May 2024 06:23:29 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id B58F56B00AE for ; Wed, 29 May 2024 06:23:29 -0400 (EDT) Received: from smtpin04.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 52289C0A19 for ; Wed, 29 May 2024 10:23:29 +0000 (UTC) X-FDA: 82171046538.04.8698A57 Received: from mail-lf1-f44.google.com (mail-lf1-f44.google.com [209.85.167.44]) by imf07.hostedemail.com (Postfix) with ESMTP id 4E8AF40009 for ; Wed, 29 May 2024 10:23:27 +0000 (UTC) Authentication-Results: imf07.hostedemail.com; dkim=pass header.d=suse.com header.s=google header.b=EGE5NVLp; dmarc=pass (policy=quarantine) header.from=suse.com; spf=pass (imf07.hostedemail.com: domain of osalvador@suse.com designates 209.85.167.44 as permitted sender) smtp.mailfrom=osalvador@suse.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1716978207; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=cv/PfQ3ipIos9jd7Od+Go1+GxK7Z1oC1HCEzh3CcJkw=; b=D+gRzbcYm++7SmOY52Z3fTeXFhDvr63lr+IvEye0RhUMpc9r8ezIndTD+sAyU2ygManePd 8MeHTuf1ZDQY7pH9J69wgW8FZR0kS533EtC9qbEEVNEdOHnhpVZQ902dWzvuUaxtLOpy1U uvAqH9oCx70gPn4bnRMmECKLQCmY3vQ= ARC-Authentication-Results: i=1; imf07.hostedemail.com; dkim=pass header.d=suse.com header.s=google header.b=EGE5NVLp; dmarc=pass (policy=quarantine) header.from=suse.com; spf=pass (imf07.hostedemail.com: domain of osalvador@suse.com designates 209.85.167.44 as permitted sender) smtp.mailfrom=osalvador@suse.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1716978207; a=rsa-sha256; cv=none; b=HyY4sFGwsWsJvMv6ToWdVzRA+vZ9l4dnjZopCa0edZ4JYUxOLvutNCaO9qpmqxx5U19fj9 FEcbGeyTfRfzppYiFSUbLroSeN6aPYfKZvtruHnvUq+jCvX01BAyM1Y8FSAOCDvd4CAEOz wUM4IkVnaW+Y6zjLnX80xXrVk16vZss= Received: by mail-lf1-f44.google.com with SMTP id 2adb3069b0e04-52b4fcbf078so329835e87.0 for ; Wed, 29 May 2024 03:23:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1716978205; x=1717583005; darn=kvack.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:date:from:from:to:cc:subject:date:message-id:reply-to; bh=cv/PfQ3ipIos9jd7Od+Go1+GxK7Z1oC1HCEzh3CcJkw=; b=EGE5NVLpRRBQn4JwOvUOcv3pyBX0YvG2XhRMZ/yK9OreBmleBL44O05oOzYAYu7ZUI c/X1tcpYfumxUHcZb+AdFFYiiWj8TJKDIE9HDBsqI+enUo2OI3X+f+c5OBJesDTXzgsa TDYG3HUJCArOra/0gCwRxdHJH6OJHVXSDHpgK4e9eCFK7kkTh01i29mSOpDTkGWkJBEn Zwjzn9s2jEKX0QGJJY6x1518Q0rufrTRnDOv7SMmdDMg4jtSQuJHKN7rVT32G2dYWhVd wftr/TLFgZQOsL/WD1cY6DjDJVSYHiqR4TL4FGJTXrH27xw/UPAjX+vnreo6BYcgAdD2 F7kg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1716978205; x=1717583005; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:date:from:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=cv/PfQ3ipIos9jd7Od+Go1+GxK7Z1oC1HCEzh3CcJkw=; b=srrNuR579EjLUPAMMLGICP1Gxsix1cV0FCxFM8e3xLJtNkOLUg7j/XbqP1uj5IPXMM 6KeX0o13LB2JAf+Pkhy6yGudQCLIAuXUk+iMyt5kCn+CFkQTZOEIEV4p1nBVe6ADkgNK 8FrczYSrlrBb+J2yIh688RKWEk+AqAShnSwQocqDIkNulh2BOWxm0dEMTiNY0SMB8m/H xhTd+Ot5nG91GKVy8W38dxFNjiQ5t1J8xjVmFEXoescspjmvzzwnv3x+ySkVpji8dTiG G1AaO85uZiNAHBU9IqkylBCIOgDM39efq0xXq1qxmfuhsgHMic4SKdjJy6Y4K4uZxp7M SApQ== X-Forwarded-Encrypted: i=1; AJvYcCXyEb4WySTkMa5kua13927UjkuYeQslPRmS5n3SlqQNQJ8XPEqQMDL/UeM8C5Y8+k3TlxOFNQjJKSkP1gWYOWpXgmk= X-Gm-Message-State: AOJu0Yz850WBjq4mzacXLqWeUXMzSLsXwJbi7cj0gOHSWix1tQzI3FLP T9R0eFJbfOT3ggwIIofYBUT+VjWg5qxqnlPT+awrTZmS59etd6ST3TAdwkSCgno= X-Google-Smtp-Source: AGHT+IF7IgN4nPJ8uxsJPr2FPONLdRAirmEdNuIVjpikXZwr3Zpn2fZcBlzyhSXu1nTASxB+UaNCCw== X-Received: by 2002:a19:7717:0:b0:51d:8ff3:d156 with SMTP id 2adb3069b0e04-529645e3335mr8922884e87.19.1716978205294; Wed, 29 May 2024 03:23:25 -0700 (PDT) Received: from localhost.localdomain (62.83.84.125.dyn.user.ono.com. [62.83.84.125]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-42100f759f0sm201856835e9.28.2024.05.29.03.23.24 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 29 May 2024 03:23:25 -0700 (PDT) From: Oscar Salvador X-Google-Original-From: Oscar Salvador Date: Wed, 29 May 2024 12:23:23 +0200 To: Christophe Leroy Cc: Andrew Morton , Jason Gunthorpe , Peter Xu , Michael Ellerman , Nicholas Piggin , linux-kernel@vger.kernel.org, linux-mm@kvack.org, linuxppc-dev@lists.ozlabs.org Subject: Re: [RFC PATCH v4 00/16] Reimplement huge pages without hugepd on powerpc (8xx, e500, book3s/64) Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 4E8AF40009 X-Stat-Signature: qggnmk1yqzyzrqdbsc4f4wp41dppwxsb X-Rspam-User: X-Rspamd-Server: rspam04 X-HE-Tag: 1716978207-701718 X-HE-Meta: U2FsdGVkX18N8lACWmZKXD44a4i0lOscdDOh2WTPpV5htr6S0O03006D0CSiG4pAXmH+P9RjMKYMXWf10d2DlmvlBnY+HW11/k8S1DTlpSA7iaIjJrCAxC72+PxEaiuZHzQpfNTMQCn8d2ioX6fapWDNoOM/J4VwjJ6SBq6tNcNb7S5vYdnXksE56L4zAyZANp5nzC0cHpAUCzKqjWoh2JjsFqSJzZ+LgNmLk1YsKttF3u6sz4zHUI8nEmW+1BFXpvei/xOZqvsIL+HOXOcmk/1BgkYweYkq5gJ3YWUybOmfeG2cZpCp/f9LfeKmLZKzsYhnK/bRGj0Xms4AxUzM/jFAsExkZpRqxDnHBJleQ/Xtb2l2LGfo6xY8lEDYZOdBb5afHaakyTb0ltmXHB3XSvX1IN8Xd5yKIQAPd/ieI6zo8SGm+y1qXByzCQfAvlNJZXIx4/fGXC4EmIZLa+cGIF/Z9DVevDHMblWyxsrWT47yitBAbG7k5mfTqnhxX6qxi2NVL5SwEcO7GH4rFKlqRW0GxIy2mgo3nBoRmSNukDTxGopiZpqbbASciWuZoE/g5glhSOkGfEtjWnPSFrKdoJZGIi2Mo/feUzKHG2vyScf29+sE76X1WAZCjqGrkZm9cfG7Lo9r8wapnUYgmw6CfyvvKQbhtzRPfoFqcD7QAcq/QYVHaLWv7QRKmfFoAFl3EGaTBtYH+KoS+mLrOmSgZiWS0n4WKhAdwP6hc3ftfLUvEto6hNT27SB4duxOuj1iLU+qnbm/k1KQEPacU3ACU1TGK0oiaHtk/zDJvuS1ND+TTaM+N9IZG156j5q+yP5h6r1ZG451VLQX5OZrW0pNcY/BC68JD5ZB8DIM//PhUG8V6C18V14h9KK6dN3skXaF/iPjYwaf6LpmBvqr0hOVwgKabWRu2J1u0+g9/aJuL/p93n/IPSyfjcXN+12ZqeHgFDLD6mlZTFLUGLpNU00 Axdl7uq+ HAYzYjvx65VKjo4sZHGswGk85DcEMiFYzlWBNG9kZmQsE+npmh+9DKlJKDex82iyJ4O3W3h22srtiFSbVOOo5XfHEdj5N5dcfewX+Z85tcnp20SYB7pHSzn+o82RVHK/oe8wrD2qpQ5pncsBe46O2h2hd78hC2p/RmjS8jhx+c+ZPbBs+3/mkyJtpJCPZq2Rh4Nc8ctsi+Z1cS5oPwqRhjMurhE/DhpM9q+Zy1WrXPBZ/mpnz0rJ0p+4pPecR0U8Jgbt1vNK31sxRDPsh/74z5zR7EX7Fi2Zgf0gcj7eazgR5Luq0kjTIzcZLgKbBxPbaqv3PYJJXYcLd2ZQ= 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 Mon, May 27, 2024 at 03:29:58PM +0200, Christophe Leroy wrote: > This is the continuation of the RFC v1 series "Reimplement huge pages > without hugepd on powerpc 8xx". It now get rid of hugepd completely > after handling also e500 and book3s/64 > > Also see https://github.com/linuxppc/issues/issues/483 > > Unlike most architectures, powerpc 8xx HW requires a two-level > pagetable topology for all page sizes. So a leaf PMD-contig approach > is not feasible as such. > > Possible sizes on 8xx are 4k, 16k, 512k and 8M. > > First level (PGD/PMD) covers 4M per entry. For 8M pages, two PMD entries > must point to a single entry level-2 page table. Until now that was > done using hugepd. This series changes it to use standard page tables > where the entry is replicated 1024 times on each of the two pagetables > refered by the two associated PMD entries for that 8M page. > > For e500 and book3s/64 there are less constraints because it is not > tied to the HW assisted tablewalk like on 8xx, so it is easier to use > leaf PMDs (and PUDs). > > On e500 the supported page sizes are 4M, 16M, 64M, 256M and 1G. All at > PMD level on e500/32 (mpc85xx) and mix of PMD and PUD for e500/64. We > encode page size with 4 available bits in PTE entries. On e300/32 PGD > entries size is increases to 64 bits in order to allow leaf-PMD entries > because PTE are 64 bits on e500. > > On book3s/64 only the hash-4k mode is concerned. It supports 16M pages > as cont-PMD and 16G pages as cont-PUD. In other modes (radix-4k, radix-6k > and hash-64k) the sizes match with PMD and PUD sizes so that's just leaf > entries. The hash processing make things a bit more complex. To ease > things, __hash_page_huge() is modified to bail out when DIRTY or ACCESSED > bits are missing, leaving it to mm core to fix it. Ok, I managed to go through the series and provide some feedback. Sorry you had to bear some dumb questions but I am used to x86 realm where things are farily easier wrt. hugepage sizes. I will over v5 when you send it, but I think this would benefit from another pair of eyes (with more powerpc knowledge than me) having a look. Anyway, I think this is a great step in the right direction, and definitely a big help for the upcoming tasks. I plan to start working on the walk_page API to get rid of hugetlb specific hooks basing it on this patchset. Thanks a lot for this work Christophe -- Oscar Salvador SUSE Labs