Received-SPF: softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) client-ip=23.128.96.19;
Message-ID: <e9456223-c26a-4d49-2920-9a597a817190@oracle.com>
Date:   Tue, 31 May 2022 10:00:21 -0700
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101
 Thunderbird/91.9.0
Subject: Re: [RFC PATCH 1/3] hugetlb: skip to end of PT page mapping when pte
 not present
Content-Language: en-US
To:     Peter Xu <peterx@redhat.com>
Cc:     linux-kernel@vger.kernel.org, linux-mm@kvack.org,
        Muchun Song <songmuchun@bytedance.com>,
        Michal Hocko <mhocko@suse.com>,
        Naoya Horiguchi <naoya.horiguchi@linux.dev>,
        James Houghton <jthoughton@google.com>,
        Mina Almasry <almasrymina@google.com>,
        "Aneesh Kumar K . V" <aneesh.kumar@linux.vnet.ibm.com>,
        Anshuman Khandual <anshuman.khandual@arm.com>,
        Paul Walmsley <paul.walmsley@sifive.com>,
        Christian Borntraeger <borntraeger@linux.ibm.com>,
        Andrew Morton <akpm@linux-foundation.org>
References: <20220527225849.284839-1-mike.kravetz@oracle.com>
 <20220527225849.284839-2-mike.kravetz@oracle.com>
 <YpUhe6BSfflOVz7b@xz-m1.local>
From:   Mike Kravetz <mike.kravetz@oracle.com>
In-Reply-To: <YpUhe6BSfflOVz7b@xz-m1.local>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?TStNelhmTC9wd2hkblZIbW9oc2FoUUl6TzdSVUlIMUJ4a3I2OTZkL2diM2NG?=
 =?utf-8?B?cXlGTlk3R3d6ZUI0M1owSDJXcWJVdmpHejZnbGU1dUhCdXJhTmxZZEV5QmdT?=
 =?utf-8?B?MGRsNWsxM3NDaU1pOFdMWlJwTHR5UUZ1QXIxZmFpUDhsWXd4QW0vYjF1TEZz?=
 =?utf-8?B?b0djM3pLTnNGcFE3dnZsT2hhZjYvTGlPSVN2b3NLNmlwYWpvM2R3dmpPejUw?=
 =?utf-8?B?YUhIY3YrWnhZS3l3NnNjcnp1RndreTdERzhVeDBmcitlcEgzK0MzYnNNMlA2?=
 =?utf-8?B?RFlJMWVaZElMRk9BdTRlczZpb1pkdE4rcVEyOFZVR2VPZ3Z0cTcxWm9uanRI?=
 =?utf-8?B?MjJCaFVPN0xFd3pLWVVydFExaDhYOHpyTmJYMXliZEdFdkJBYXZFbG5FRmNn?=
 =?utf-8?B?N0VHT1AwOGJ2SlM4dVhHM3VRclF1aHhKWXhTdVdpRGhDRTVPWFJ5QUs4Nmwy?=
 =?utf-8?B?elZ4RTZpbk5TUXR6RFI5WStZNmpLOVR3aDBwR3RSR0JSRFBrUjJaOWFCTmpk?=
 =?utf-8?B?TUhPelRWOGlzb0NFaTlNY3VwQmV2eElCNG5YUlpKQXd3a0d4U1RPT2o3R091?=
 =?utf-8?B?ZkM5c2d0bE5xTGI4UGU5eDkrU2xaM0syTlR1cWMxTE05UURTSExjY3h1YXQ0?=
 =?utf-8?B?MDN4ODhGeElCTjF6ZkZRSDJOdzIxakRLZjB4UTVwaFJzVmF6TlZxemdvMnhh?=
 =?utf-8?B?dmx4eTJvcFN6WGM2K0xVendUMzVCdTFKOFN5WFg4VVhyQllJOW9heHNCdjZ6?=
 =?utf-8?B?aFVlN3JnSzFDRE5KcFRwYUsycHdmd1Q1cEpHTzdTNjhHM2lNUzlSV3hQY0Fr?=
 =?utf-8?B?Slc2UjRYMUgwdlF2TGV2MjM2NXY0a2lzNWplcTcyait3eGYrWUZYVEszSXhR?=
 =?utf-8?B?V2FTbHoxUkJzZXZxZXcxSlhNVGkvWEl2UzFsMDdONHQ3TFFkSDlhYUJZMTcy?=
 =?utf-8?B?OUZBWnlDelRUNVQwQ25abkxRc0tSRENKZS9iMms2QXg4NGE1c1lrR0QvTjNY?=
 =?utf-8?B?Tit5S21MTklBVmtJc3lzYVh3blR0ejN6Sjg5M2RadmZESlJQTzdLblM5WitI?=
 =?utf-8?B?T3RLNE9Ia1ZWUVE0WHh1NzhodWdHTEJhVlZYUXBQc0hTTWphQjkyNUpjOHM2?=
 =?utf-8?B?Wi9TQW0vRmgrNTJGUTM2TVdQU2thZFh0QW1FWldodFNvWXp0V0hQdnNkYk1W?=
 =?utf-8?B?RjBMazYxUEJveXFOQkNKSUpCK1BOaHc5eVZEbk1jS2liUUlTeTY1VkQwZjIr?=
 =?utf-8?B?MG11TTQ0QnVSUTNjdE15ekY1L0lQNGU2WWpUZDlTM0tTaElQWUdBQ05YRmtD?=
 =?utf-8?B?VkltY0kvZUNyUitFOEJkSHkva29qdS91TEYzcGhCSGNreXdNVUJhSlV5V1Ix?=
 =?utf-8?B?bXNlRVBrVUxZMkl5ekNhc2xjSHdsbTIra0JZUWZ2QVZJeGVUdWdiMXdzMG13?=
 =?utf-8?B?NnJsZFk3b0c1TXMzc1c5Wktkc2xDTHMrdngra2gzVTJjbnBIUUxzd0lyYXBM?=
 =?utf-8?B?MTNpMnBIVGNSR0kwcUx0SHRMMm9FeXNSSHpRK1loaVpPVkpJclZIajQzZjlD?=
 =?utf-8?B?UENYaVFPOVZaRVFSTUZRZEFOVGlRTUVZRmVNc2Z4dGFtQmJNZmRMbVZBdHFY?=
 =?utf-8?B?RnV1Z1FoSHBUWnhBQllEd0VINloxSzVTWFZOVkNYbFRCakV6VXBWZ3cyU0xj?=
 =?utf-8?B?WU1JZ3ZwV2J2SVJtWEEzVG81T2ZiT2ZQUjQvdWkzRVVLZDVuWkp5WjRuRDhJ?=
 =?utf-8?B?OVpiUVErQXBFV1MrdnM3VVR6eHZFMGZEb2hBN2hMamJ2QjArSVpBWGNWUmRK?=
 =?utf-8?B?YUdENklXbzFUcVJjd0VUbDcvU3NHR2Jrb3diWHlxdFZIYk9KYmdDS1FzM3Vv?=
 =?utf-8?B?Q2hqSDk3MS92blZTcmY5Y0JNOHd1cjk5Q2pGMWJRNXc4VjJ1aWJWdkJrVVVs?=
 =?utf-8?B?NWlHRFFLditvcHNnVGZRVXRFTThYckJyUWdFc2hmdWNudUhxQWN5emQrdkpQ?=
 =?utf-8?B?WWdWL1psYjRhUUlEb20rSmozcVVCa0ZZbERNVURGb090RnNkdjNZZ0ozUW9v?=
 =?utf-8?B?TW0wN1o1ZnlqUnkwaXVTa1BRM0lwTHYwaDErVmhWdnE3MkwzZHlzUWRnazE4?=
 =?utf-8?B?K1JPQXhsQ0o0bDBqN1RaMDBwRUhUakhWOFptUmVuazFEUjFSWEVuQ3RLYXRn?=
 =?utf-8?B?L2hiUDJaMzJ1OG9PNlc4RGg3V0E5TU40K3NFK0QyVzIrR1pCUEFXb1AxRmZT?=
 =?utf-8?B?VFJ5R3p3emJ5cjlnMEx6YVZ1NzVLaDgwdWNQbUovTThzQ05vT0gxUUkyNjFx?=
 =?utf-8?B?ckNxRDQ1QTNMUWoyNTQvVHpyY0lsbi92aU5US290cjdmZGFGc1hQam1Ub29P?=
 =?utf-8?Q?HzKEYSGFkDg+/J5Q=3D?=
X-OriginatorOrg: oracle.com
X-MS-Exchange-CrossTenant-Network-Message-Id: ae3e85a8-1f68-45dd-96a1-08da43270ddc
X-MS-Exchange-CrossTenant-AuthSource: BY5PR10MB4196.namprd10.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 31 May 2022 17:00:24.3254
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 4e2c6054-71cb-48f1-bd6c-3a9705aca71b
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: WLbTPR8hmTZIbpUk1Jac8DCmKUMdfmmfBIZ0TWdHUCuXrj00FQE/Mw3ECVfR5LOQXad7l+dR2i8OP28jNvq2kQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR10MB4468
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.517,18.0.874
 definitions=2022-05-31_07:2022-05-30,2022-05-31 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 adultscore=0 mlxscore=0 phishscore=0
 suspectscore=0 mlxlogscore=999 bulkscore=0 spamscore=0 malwarescore=0
 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2204290000
 definitions=main-2205310080
X-Proofpoint-GUID: lJKn2dSNQk85-MMeq5KuV08Cc1-aHpeh
X-Proofpoint-ORIG-GUID: lJKn2dSNQk85-MMeq5KuV08Cc1-aHpeh
X-Spam-Status: No, score=-3.2 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,
	MAILING_LIST_MULTI,NICE_REPLY_A,RDNS_NONE,SPF_HELO_NONE,
	T_SCC_BODY_TEXT_LINE autolearn=unavailable autolearn_force=no
	version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on
	lindbergh.monkeyblade.net
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On 5/30/22 12:56, Peter Xu wrote:
> Hi, Mike,
> 
> On Fri, May 27, 2022 at 03:58:47PM -0700, Mike Kravetz wrote:
>> +unsigned long hugetlb_mask_last_hp(struct hstate *h)
>> +{
>> +	unsigned long hp_size = huge_page_size(h);
>> +
>> +	if (hp_size == P4D_SIZE)
>> +		return PGDIR_SIZE - P4D_SIZE;
>> +	else if (hp_size == PUD_SIZE)
>> +		return P4D_SIZE - PUD_SIZE;
>> +	else if (hp_size == PMD_SIZE)
>> +		return PUD_SIZE - PMD_SIZE;
>> +
>> +	return ~(0);
>> +}
> 
> How about:
> 
> unsigned long hugetlb_mask_last_hp(struct hstate *h)
> {
> 	unsigned long hp_size = huge_page_size(h);
> 
> 	return hp_size * (PTRS_PER_PTE - 1);
> }
> 
> ?
> 
> This is definitely a good idea, though I'm wondering the possibility to go
> one step further to make hugetlb pgtable walk just like the normal pages.
> 
> Say, would it be non-trivial to bring some of huge_pte_offset() into the
> walker functions, so that we can jump over even larger than PTRS_PER_PTE
> entries (e.g. when p4d==NULL for 2m huge pages)?  It's very possible I
> overlooked something, though.

Thanks Peter!

I did think of that as well.  But, I mostly wanted to throw out this simple
code while the idea of optimizations for sparse address range traversing was
fresh in my mind.

I'll take a closer look and see if we can use those general walker routines.
If we can, it would be great.
-- 
Mike Kravetz