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 791EFC25B74 for ; Tue, 21 May 2024 11:57:27 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id D65EE6B00AB; Tue, 21 May 2024 07:57:26 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id CEF0B6B00AC; Tue, 21 May 2024 07:57:26 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B67506B00AD; Tue, 21 May 2024 07:57:26 -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 93BEE6B00AB for ; Tue, 21 May 2024 07:57:26 -0400 (EDT) Received: from smtpin24.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 3E5711A10E7 for ; Tue, 21 May 2024 11:57:26 +0000 (UTC) X-FDA: 82142252892.24.4E9E748 Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.223.131]) by imf11.hostedemail.com (Postfix) with ESMTP id 1500B40012 for ; Tue, 21 May 2024 11:57:23 +0000 (UTC) Authentication-Results: imf11.hostedemail.com; dkim=none; dmarc=pass (policy=none) header.from=suse.de; spf=pass (imf11.hostedemail.com: domain of osalvador@suse.de designates 195.135.223.131 as permitted sender) smtp.mailfrom=osalvador@suse.de ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1716292644; 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; bh=dzeVyW39LqoyWWLKyKDjxIhWpkob/DeWMnc6kqHfElg=; b=qjBaOgGO5kQEfQs5xhMWGAhjkEgJXWU38sPKxdcsaeR116IFkbDUzZKytpJIuoOvH54gPO GPFP2cbVYW1TqDogpCBtinil+Dtr1P/XhsJUrW0oisaDwHEf/egKIL4ZUU9wUiqIPc8sfD VnFvB/B7ZPtpH0I3CVfgjVa5Q+s3RCI= ARC-Authentication-Results: i=1; imf11.hostedemail.com; dkim=none; dmarc=pass (policy=none) header.from=suse.de; spf=pass (imf11.hostedemail.com: domain of osalvador@suse.de designates 195.135.223.131 as permitted sender) smtp.mailfrom=osalvador@suse.de ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1716292644; a=rsa-sha256; cv=none; b=KQlpXb/NKqF3zYFB0LZ212wdlHwc4nPYMX931WrQbV3d8HuzoUrR10RHs7wvuMSETpSSN1 /UqFKRboNdagiaV2sN1oPZtQda7xVeXxcAqdk3C/RJtLPh8PxSnrFOCaO7KGA2fJVfAbrY +ZkhqDyDMeyWfUUDUJ4cB1ws9VlJkVo= Received: from imap1.dmz-prg2.suse.org (imap1.dmz-prg2.suse.org [IPv6:2a07:de40:b281:104:10:150:64:97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by smtp-out2.suse.de (Postfix) with ESMTPS id 64D505C0FA; Tue, 21 May 2024 11:57:22 +0000 (UTC) Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id D202413A21; Tue, 21 May 2024 11:57:21 +0000 (UTC) Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167]) by imap1.dmz-prg2.suse.org with ESMTPSA id 2qi3MCGMTGZncgAAD6G6ig (envelope-from ); Tue, 21 May 2024 11:57:21 +0000 Date: Tue, 21 May 2024 13:57:20 +0200 From: Oscar Salvador 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 v2 01/20] mm: Provide pagesize to pmd_populate() Message-ID: References: <91159d49bcbee0526ca6235ff7ef1ee7d378d013.1715971869.git.christophe.leroy@csgroup.eu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Action: no action X-Rspamd-Queue-Id: 1500B40012 X-Stat-Signature: 5y4tufdg9h7qnxm4ishar44qm9zgzjhc X-Rspam-User: X-Rspamd-Server: rspam08 X-HE-Tag: 1716292643-140905 X-HE-Meta: U2FsdGVkX1+/lZ/I8v33gIiYosqX89nuWlmVi3vAJkJBOWryLO7sh3+SZOmxRt/Sz0vDy1aFq8S+WGpVtHX6uWbilkPzKqM8vM1cN03XbsoIwD3QRV1U8G2/nPmfN5XYSZiZOxhlMVJF42QFBbBsL/KLt1L65hCYmyso7ki/rPXcDpemj54BMWIIG+tfEA8BcK0oFUu7d+DYm9FaYP0lZZy6bVw4HA6S7lvVaH5x/AipHahPDhi6DHoh33YDDPeDq/BU5o8a7eE40LIV8Bm45uEKCGkKw4U6AEzXqONq7p2C2F1YCeXAywB25d3Rdcaq4AfD0aHh/xNo+L0F22sbZSA4ZLstyGDw8FgrG9o/+pk96Gqc3lqHafqu/tWMCSHa1tSNDf0iFxAdFmVMk6SXhkHP3rVfun1t6oTOIkoioZqY8+qzhGPP0dx5/+2fLmCKhVffJXZD4q6Z9pA+6+bC99wcGV/PfrrL/bcDGQFtkNlws9yl59FvC6yDe8UvZYZg/ZysssRPfq0DbU2dSL24U40Sr3nwekuqZTOpmuuhvbBX65VU0n61qvQ3+mTM+g0JwzXwUxwsTB9p5UeHTwE5jEWBCSGIzFCjGdAD9K1gdHkF9Wf+jQtlIdLMk4ULAKF2oMYfhT0q1Fjsh9Npx3lxEy/I5XeA5veMFdj2d409kmcxWsdMs0q1ihUPH5olr9i7zrboA2uyvfJjEtffJYvlbE+F9/69Yh/a6lQ0OdnmQmCh3UjCeShhvWKHw16SVh1p677FUQyhrLrFW4OOo1AxLxCg1aW/+Cu6tfcyZXF7s7kGso5OEK+MzYxHnkyO4SdOn3pDFHQdqR8jahDLNGjY5/NevCUwTTepbSIqUG/NYk4vwMjALW842FtR+L6B3ilhMotrwgpb5Bs/e1EbAdmjVTxdONDN6N/D4zHuayAjv16KD2C1tnEOvRP4EOt/c3lPpqQ1Ik4NcchKO73Fz5W 31MmQL1m TGFlN+bN7qlmf/7byWy79sZdoTGLqqKkaHZHgF4XO4/PuRDGQSj41fDyaR3flVdMU9KWirScga9YgYNaS/Pa8ByVunzltlNv9N9tTdiaXyS3lCJvAddQbkVJ8zYVdWANR3hMXQGvkjf5BHLB4GkVqqSzek/vVXTHCHDtnFiRhYaHlEQZEwRuWZMp+Vg== 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 20, 2024 at 04:24:51PM +0000, Christophe Leroy wrote: > I had a quick look at that document and it seems to provide a good > summary of MMU features and principles. However there are some > theoritical information which is not fully right in practice. For > instance when they say "Segment attributes. These fields define > attributes common to all pages in this segment.". This is right in > theory if you consider it from Linux page table topology point of view, > hence what they call a segment is a PMD entry for Linux. However, in > practice each page has its own L1 and L2 attributes and there is not > requirement at HW level to have all L1 attributes of all pages of a > segment the same. Thanks for taking the time Christophe, highly appreciated. > rlwimi = Rotate Left Word Immediate then Mask Insert. Here it rotates > r10 by 23 bits to the left (or 9 to the right) then masks with > _PMD_PAGE_512K and inserts it into r11. > > It means _PAGE_HUGE bit is copied into lower bit of PS attribute. > > PS takes the following values: > > PS = 00 ==> Small page (4k or 16k) > PS = 01 ==> 512k page > PS = 10 ==> Undefined > PS = 11 ==> 8M page I see, thanks for the explanation. > That's a RFC, all ideas are welcome, I needed something to replace > hugepd_populate() The only user interested in pmd_populate() having a sz parameter is 8xx because it will toggle _PMD_PAGE_8M in case of a 8MB mapping. Would it be possible for 8xx to encode the 'sz' in the *pmd pointer prior to calling down the chain? (something like as we do for PTR_ERR()). Then pmd_populate_{kernel_}size() from 8xx, would extract it like: unsigned long sz = PTR_SIZE(pmd) Then we would not need all these 'sz' parameters scattered. Can that work? PD: Do you know a way to emulate a 8xx VM? qemu seems to not have support support. Thanks -- Oscar Salvador SUSE Labs