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 27FF6C27C44 for ; Wed, 29 May 2024 09:23:26 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 92AA16B0099; Wed, 29 May 2024 05:23:25 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 8DAF76B009B; Wed, 29 May 2024 05:23:25 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 77B456B009C; Wed, 29 May 2024 05:23:25 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 583A16B0099 for ; Wed, 29 May 2024 05:23:25 -0400 (EDT) Received: from smtpin30.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id AA67F1205AE for ; Wed, 29 May 2024 09:23:24 +0000 (UTC) X-FDA: 82170895128.30.A1A7E34 Received: from mail-wm1-f41.google.com (mail-wm1-f41.google.com [209.85.128.41]) by imf29.hostedemail.com (Postfix) with ESMTP id 98F8B12001C for ; Wed, 29 May 2024 09:23:22 +0000 (UTC) Authentication-Results: imf29.hostedemail.com; dkim=pass header.d=suse.com header.s=google header.b=ZuynV6gV; dmarc=pass (policy=quarantine) header.from=suse.com; spf=pass (imf29.hostedemail.com: domain of osalvador@suse.com designates 209.85.128.41 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=1716974602; 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=fhJ836irwNS/8JeOTE2TBDDML/9+Ts5hKkWKN+MrauU=; b=liC0CXc+eTZBMsxpWh/1SBcz5TQk9JL0ohudrM7hzgaJuxQwhbBT5OKa6D1BSBpb/xJfDg zyoMJ2z3q51Ow0Sok/FkIEvV/BKhmn/7yucTeLK2RT99gDyB+B4jAkcGlob5w3eaBBmMOp 7CTBw/bi25eEnJSAIZkODaNmByJ+v2s= ARC-Authentication-Results: i=1; imf29.hostedemail.com; dkim=pass header.d=suse.com header.s=google header.b=ZuynV6gV; dmarc=pass (policy=quarantine) header.from=suse.com; spf=pass (imf29.hostedemail.com: domain of osalvador@suse.com designates 209.85.128.41 as permitted sender) smtp.mailfrom=osalvador@suse.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1716974602; a=rsa-sha256; cv=none; b=XPVQQ1a6aaxYYx9p12TGSuymFcz6SwFPwvD16Z+keO4jsVVnI66q86wkEsDfZX5MG8sYgE jhL+m7vmLb7FoxG+icZhXDFWiMkrOgwgmf8TtTqnr436H8pROvLxGyn+s5iD/3ob4WRhjs LjUFfrLuXrHQl9+daREolMpvb7Nfbbo= Received: by mail-wm1-f41.google.com with SMTP id 5b1f17b1804b1-4202ca70318so15936235e9.1 for ; Wed, 29 May 2024 02:23:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1716974601; x=1717579401; 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=fhJ836irwNS/8JeOTE2TBDDML/9+Ts5hKkWKN+MrauU=; b=ZuynV6gViE9kQcU10vmRAhKTtdZlY93Z2hE4nJlbHO8ft6OS3kTqhoqSIsyqkMZT2P sPcd8Ghz/TvkdeoRUl8ZSHKMRDfeYVRrg19rtNW98pgUbTOY/Iib7y2GZ1MdjN2c5za6 Rk0Sd48fj9TCaiq9u74SycgzVJxf47RUxzi6kofLSjA8sy3Ldhau7eBE1DF924jwzm/E t8WpcHRhTMrzIkFYBaRgZHHJ9CUhKKlZTSW8URt580S+ykPKoioCJJDtQhZn/5QJ+uzT G3ycFVyfWAXsf/JGcALpX/8uakh8Gr2BPFKkBKyY08aD5bu+zoOhTvppJ0l+440LPlDj FPEg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1716974601; x=1717579401; 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=fhJ836irwNS/8JeOTE2TBDDML/9+Ts5hKkWKN+MrauU=; b=M0e4zDm3yRAPZRPo9L8aBAVIf12AOtd3lOjR2vajCtCnLRDq5/D8pDPF/l9hVSNqf0 D62GoCbODu1FRAvqnjDyGECd8B/HdI8ImJO2WOS03iECmO7GPTpo7krc5X/JtkerY0BB XU1HvOCgt+TMUn0YOlbQEVozRmsVMibKbrbCaUDxt4xBkeKPPO+E8wEob7kKB/BFDUMt Gm+r/E2aV7NESqeL/uATHt/0fCmJ/qoLLWnZjtuNRtx6GJM2qrGHFGpd2vfjD2NM5Scx XAeOCAN5dKgwqp9hVVnVxsnEW3gWRoZwJ2ovMOUPAqZJl2aIPAWQ68/Pq0m0DUUV6pOd OhCQ== X-Forwarded-Encrypted: i=1; AJvYcCVI+6lk9DA6BGfPolahIqv6m/EbxrDzwGAA0L80Gej7JxlWcJh+axQiE871tCQC7/4KoNH4xoRp0sua/ZZpTETSTRg= X-Gm-Message-State: AOJu0YxBK6MiK+zqXm6SF5ovrqlVX/oL1cCLFO7Zo1XdsFUUGPL9PZ3R kYqw+iNanVaX8Xyon0IkTdVIcdfVfvzJpmsnu0Lz/zmnfc6vK7lVUTca2m52lnY= X-Google-Smtp-Source: AGHT+IFm78cnc3X0c1k2D4eGRsFsXjAbi0O/Q9Jcd6v24wtsbWarGavak3rEikXZrSA/XmfQUHqeuA== X-Received: by 2002:a05:600c:3144:b0:41a:c592:64ff with SMTP id 5b1f17b1804b1-421089f9787mr136068615e9.35.1716974601075; Wed, 29 May 2024 02:23:21 -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-421089708edsm173311555e9.16.2024.05.29.02.23.20 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 29 May 2024 02:23:20 -0700 (PDT) From: Oscar Salvador X-Google-Original-From: Oscar Salvador Date: Wed, 29 May 2024 11:23:18 +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 14/16] powerpc/64s: Use contiguous PMD/PUD instead of HUGEPD Message-ID: References: <610be6003a6d215e9e9ca87d7f5402042da1e355.1716815901.git.christophe.leroy@csgroup.eu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <610be6003a6d215e9e9ca87d7f5402042da1e355.1716815901.git.christophe.leroy@csgroup.eu> X-Rspamd-Queue-Id: 98F8B12001C X-Stat-Signature: snwn4s3wbxrcqjbaabmrjzij6efab19t X-Rspam-User: X-Rspamd-Server: rspam04 X-HE-Tag: 1716974602-452093 X-HE-Meta: U2FsdGVkX18WN7jKaloKPnAGcG9CgOMu3YL7wwjobglXEJVRUHkQKBrFKy2Ifn+bk/Pg+Y0f9OpL/2lcrnZBPQmrXc5NgSFjBKW2Q+mSJHWv5yHDgxHAUbXslsJc8FfQNuT6YkwujpANAXRc8km6z9a/UrWaNAb5jG1PEBXtQ9O2XFuV0LyKjOOWPg6EN4ZIFek8s8GnuU9bWM17CJ43jCICmZi0q9z/uDtsx+PG1ll6pqpz14SaRkx9ELuOpItZlYeUwtRC9+glKnfVh4ay2+O9RiHZQz2xpMCn4FSwD09gyFCPsLiRaRlT36sHfsTsuG/vEP1u23QmNA/j28k0upgOuGSlDbBxto2yNYEdndPUZ7jJ2mJiZwoJzUiOx51sO4sW4DhY9GePB02fH8Axnb75KxUYrIiBtdfCSten0NK2qMS/AS5e7b0NRkLvz19w49w1vxTjhBoVHfYRNEiucpkKLynVWrmxhkuJTPlz1EDlFkvVM4/5UUXNkXGkgNZBOt9hM11sj5lZFaeddOl16MQxqQFCiiEzMOA16ihoAAxQ08G4+NP/enqWqYatjJMEvO/JaY9/AqlL/y8XyVB8HsdJZFu+T3b6f0vEw+dTzBr8QsPVSPLbHuZFSRit7fo9+iua/09zA78926ZWiaZf2hDV9hm+j+GvpwTAV3WJVUjLM9xSQj8hfmxBlvKQmdthsUS3edWE6kkC2TE9ElffHmiL0gl0d4vl8gHj91SKMs+HJ9mZY+FeGQle51jorLMa0yKIT4LQi2/MaeKzvjbpxMVjL8vv0RS8XakypOZwmPIQRpHV10yADEo8f6eFjVRceGZFmY1vG6oDjxJdAYhuvXTNpiipJ0JeZGQdurPpeeWBjS2bpigQf38odJLS7ssiOXR0Os2Z8b8zFBQjdYFMWrixlnycJi8IycSYTKsareHtPqru9wTmkj195jl0yUaKLAbIE+UAEZTmKFThQ3z 2X3jDpws pE5i1iYbURlwXQrzMUWDeudeydyzJ9jf1WSt2rnhTggowy7Hs5ABVuRSSUv/QgcsOKNQrRWTzcDi6yNrcKUh7ngVF2p/uozuf3frw4KnJTbMFCIutCJjoUOAuJkp9+AMVA3zCAP6xA5DR0HHDS/o2yEvSVysuXbM966PtVU/0puEXQw3jySqwfjlB6L2G6kJ9l/V/KZRLm9vuanSehC3L14H1wH4EbfnLUv2pxwgDCyufbtB6RXWpMA312IKX2gjiyfm9n3uhUhb/7yxLRpG5CfIIf6MAhUsVyy+PRfqutd46f0sFw2oBbtsOTw== 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:30:12PM +0200, Christophe Leroy wrote: > On book3s/64, the only user of hugepd is hash in 4k mode. > > All other setups (hash-64, radix-4, radix-64) use leaf PMD/PUD. > > Rework hash-4k to use contiguous PMD and PUD instead. > > In that setup there are only two huge page sizes: 16M and 16G. > > 16M sits at PMD level and 16G at PUD level. On 4k mode, PMD_SIZE is 2MB and PUD_SIZE is 256MB, right? > +static inline unsigned long hash__pte_update(struct mm_struct *mm, > + unsigned long addr, > + pte_t *ptep, unsigned long clr, > + unsigned long set, > + int huge) > +{ > + unsigned long old; > + > + old = hash__pte_update_one(ptep, clr, set); > + > + if (IS_ENABLED(CONFIG_PPC_4K_PAGES) && huge) { > + unsigned int psize = get_slice_psize(mm, addr); > + int nb, i; > + > + if (psize == MMU_PAGE_16M) > + nb = SZ_16M / PMD_SIZE; > + else if (psize == MMU_PAGE_16G) > + nb = SZ_16G / PUD_SIZE; > + else > + nb = 1; On 4K, hugepages are either 16M or 16G. How can we end up in a situation whwere the is pte is huge, but is is neither MMU_PAGE_16G nor MMU_PAGE_16M? > diff --git a/arch/powerpc/mm/book3s64/hugetlbpage.c b/arch/powerpc/mm/book3s64/hugetlbpage.c > index 5a2e512e96db..83c3361b358b 100644 > --- a/arch/powerpc/mm/book3s64/hugetlbpage.c > +++ b/arch/powerpc/mm/book3s64/hugetlbpage.c > @@ -53,6 +53,16 @@ int __hash_page_huge(unsigned long ea, unsigned long access, unsigned long vsid, > /* If PTE permissions don't match, take page fault */ > if (unlikely(!check_pte_access(access, old_pte))) > return 1; > + /* > + * If hash-4k, hugepages use seeral contiguous PxD entries 'several' > + * so bail out and let mm make the page young or dirty > + */ > + if (IS_ENABLED(CONFIG_PPC_4K_PAGES)) { > + if (!(old_pte & _PAGE_ACCESSED)) > + return 1; > + if ((access & _PAGE_WRITE) && !(old_pte & _PAGE_DIRTY)) > + return 1; I have 0 clue about this code. What would happen if we do not bail out? -- Oscar Salvador SUSE Labs