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 3EE3DC7EE31 for ; Sat, 27 May 2023 10:42:13 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id BEAE06B0072; Sat, 27 May 2023 06:42:12 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id B9B6A280002; Sat, 27 May 2023 06:42:12 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A89BE280001; Sat, 27 May 2023 06:42:12 -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 999B36B0072 for ; Sat, 27 May 2023 06:42:12 -0400 (EDT) Received: from smtpin03.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 65120140220 for ; Sat, 27 May 2023 10:42:12 +0000 (UTC) X-FDA: 80835695304.03.2E7A8EA Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf18.hostedemail.com (Postfix) with ESMTP id A07C81C0003 for ; Sat, 27 May 2023 10:42:10 +0000 (UTC) Authentication-Results: imf18.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=qtjpACU3; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf18.hostedemail.com: domain of rppt@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=rppt@kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1685184130; 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=0mQEmv3UUP4cU0ZANPledmQKuGyXnEeo2jp1GeZnMBQ=; b=Oh6I1jewlLgN1YzuBUFvJzgiu/xSeIV0Z47ItIXKl2XUZUyBprQ+N/zdfMRx20gnW3cCTZ KJ4WvgDzFTEK+OOb8RGr124EDzFez52L9SUUWSjFA05KMXZ6htZ9QLfYJbH+OR64GvEYbj BeqG5yjxukzed9/1lvahG+41K9B03kE= ARC-Authentication-Results: i=1; imf18.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=qtjpACU3; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf18.hostedemail.com: domain of rppt@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=rppt@kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1685184130; a=rsa-sha256; cv=none; b=ivlYKqi5vM3I26R4pkfa8Nzej3zQWQsNAIC1cHkFkGz9uSbqgbvJHvBFYFA1Ea/yXt/FTD OYhXM190/LM68EWFD0Yr9oVN+kZf4pFi2Wkka6wAHT1G3myMmIlkC5s1KblrRnfHv2hhA7 TApmkTnm1JoH5oXiOypLXkFfL714Aoo= Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 9F50861072; Sat, 27 May 2023 10:42:09 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id EE11AC433EF; Sat, 27 May 2023 10:42:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1685184129; bh=Z4TeIapFpeS1e5WxOMUpOrDg87Rxe8ydQavxJsO0vug=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=qtjpACU3i7FVjLT023Ddg5iX1Sm9mYGyR9BAcAldcZGtkGi1IgPSjR20Gkom5YVFi 9GqwWTqSe6aCGE+Jk6r1lk9ASI1BqwfpG0h2HSrQ1BaMlG84/DZwyIoKGVbNuFJs46 KM/CX4KgN01bs8ctMAmNzdH3P/7vJMOVtl/spQpp1NeNWLVBfmoG8tubTTHEz78nbM Mi5TzSK4O/LtfJpDtvhI5QLWzSn68VROvh7bVsKVmfCA0L8DXw2EUj7uC78b19+5Rx 6iPjAV5tMRrgS7SBBOhhGo75UiSObo7waKqxJ5uuMYjPYcI7MRtTbdg+ba8TB9jNgs b+IpYHQpsYW9A== Date: Sat, 27 May 2023 13:41:44 +0300 From: Mike Rapoport To: Vishal Moola Cc: Andrew Morton , Matthew Wilcox , linux-mm@kvack.org, linux-arch@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-csky@vger.kernel.org, linux-hexagon@vger.kernel.org, loongarch@lists.linux.dev, linux-m68k@lists.linux-m68k.org, linux-mips@vger.kernel.org, linux-openrisc@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, linux-riscv@lists.infradead.org, linux-s390@vger.kernel.org, linux-sh@vger.kernel.org, sparclinux@vger.kernel.org, linux-um@lists.infradead.org, xen-devel@lists.xenproject.org, kvm@vger.kernel.org Subject: Re: [PATCH v2 05/34] mm: add utility functions for ptdesc Message-ID: <20230527104144.GH4967@kernel.org> References: <20230501192829.17086-1-vishal.moola@gmail.com> <20230501192829.17086-6-vishal.moola@gmail.com> <20230525090956.GX4967@kernel.org> <20230525202537.GA4967@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Rspamd-Queue-Id: A07C81C0003 X-Rspam-User: X-Rspamd-Server: rspam05 X-Stat-Signature: q8ynijsw1efsuwpmznxsjwiwiotar1sp X-HE-Tag: 1685184130-759400 X-HE-Meta: U2FsdGVkX1/xsH69eqepmpsVnjWXIon8kqnQWxDtkfRDBeg7Nh9cebPkZSQtE/O/IY/dBTNcsHVKDlS7JDo2FP/mTQBj8gTUDoi+Trp/vT7ANOw7wy8wJJSfmTB1/F/p4kmX2bF70FAHOINSrF0GPrmKYFpn8ZIfdPooLXYoYS0gC4ddxCGMfe4OKk438kUCq7PUVxADirclT3yNAyHaF8+TDSN3/4mw9c3Kj66+ChqQ6+DexeNzupmi/7V6lgzDAHqo7INDqCv75Tl53b1Iaz5mOq6GTKhmK0sJbOK2wN1xXMOswRABhv2/1LeUkaba+pWUUugi/IhyH7NZzHEeK0uKw2rCqxAH2VDaSwk8dEzZhgmWlHi72AfYyY/iqAvMTmxFQ7hkA4rfeWSDALa3A+ISKcQ8mQgbLc+whki34ElgA65M22hsryJPZnFEJwrD5QX7XO5Fthu0drEJJwDcF2x8Ee7frJ+StfHlc0xwlAz1tEvnjlHC16rpi8e96c21LCH9/pONymkOslYJ4arcSpNisLf7VpW8Cql1wlH319rB1kM/Pu+aZdxASrdliIaelXhbS16nv1vGEajvAJ+Q2Rt53xtAMfm800ppAtsd5vLkO5XpwJTKZN6HkHENUYog2Y7ehAkOx9m1Bmgxt3I1Ovi2s7KhyqabofH3KfMEZWsHeKeTlWupNJ3nM0pV19Al1kgw7Alge30s56xIkejfWrEGIVhdKD1j+ch4hD7SojzwC2Cb7OA3iWB+AghNMX08eGFll2wxMlFHu3lcKuDR7qAwItF8LMU6nINXBuQDpvq/vtAJglf8pQwrt2SgxxIJrdMpu0t0MMbdI0O3OTLjMiABfKU2frkR0D8IoMbCsXYQrRiyxOJbkCZ9GwJaS18TMTJjeOsa47qWG0L3VUFTwkX3dEg7o5uckqvzxaT9pecrXU3BwG5N7c3WzourbN7ZJWH2LPn0ynLZIFuZCfL hGkdBnWo u1vcmjymZ8YYhH+lZlr1m4bSnReO7j6scWy0B9hp1gkghAWOvecVZIIraDV++unnTDA6kgOlJYphsKEHN+NeJabEb7jmW+AcJY/lKB9uDjhxVYYLDeAj2X58JZtTPoQ7lg3nLSwjSFmS0pQWT0ZuriFloZcMgMXxY6e2eqQQH7gakl0ITakar9XAYD4oSqjBE0ydVlnWFdKeEul4e9Wif4qC7O/jo78fQZGl5ccb+/1YLxlCSf9bDX0ka64kG5RJjs6X8GMm9oLR4J2j71LtsS7bGqBELHLlxW0//09dMakGB4imZAL/351yV8e6LXvYXMmlrP/1dpEzwqbs4qrs5WaitL2iSjeUL1RG75lfCt7uMG85b6DlaRcluLw/1PLi2gLOQvSBRbmkHGKhaHZ6b7q6HHrNy5Tw2bQpSurWlwCnN9I4= 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: On Thu, May 25, 2023 at 01:53:24PM -0700, Vishal Moola wrote: > On Thu, May 25, 2023 at 1:26 PM Mike Rapoport wrote: > > > > On Thu, May 25, 2023 at 11:04:28AM -0700, Vishal Moola wrote: > > > On Thu, May 25, 2023 at 2:10 AM Mike Rapoport wrote: > > > > > + > > > > > +static inline struct ptdesc *ptdesc_alloc(gfp_t gfp, unsigned int order) > > > > > +{ > > > > > + struct page *page = alloc_pages(gfp | __GFP_COMP, order); > > > > > + > > > > > + return page_ptdesc(page); > > > > > +} > > > > > + > > > > > +static inline void ptdesc_free(struct ptdesc *pt) > > > > > +{ > > > > > + struct page *page = ptdesc_page(pt); > > > > > + > > > > > + __free_pages(page, compound_order(page)); > > > > > +} > > > > > > > > The ptdesc_{alloc,free} API does not sound right to me. The name > > > > ptdesc_alloc() implies the allocation of the ptdesc itself, rather than > > > > allocation of page table page. The same goes for free. > > > > > > I'm not sure I see the difference. Could you elaborate? > > > > I read ptdesc_alloc() as "allocate a ptdesc" rather than as "allocate a > > page for page table and return ptdesc pointing to that page". Seems very > > confusing to me already and it will be even more confusion when we'll start > > allocating actual ptdescs. > > Hmm, I see what you're saying. I'm envisioning this function evolving into > one that allocates a ptdesc later. I don't see why we would need to have both a > page table page AND ptdesc at any point, but that may be a lack of knowledge > from my part. Sorry if I wasn't clear, by "page table page" I meant the page (or memory for that matter) for actual page table rather than struct page describing that memory. So what we allocate here is the actual memory for the page tables and not the memory for the metadata. That's why I think the name ptdesc_alloc is confusing. > I was thinking later, if necessary, we could make another function > (only to be used internally) to allocate page table pages. -- Sincerely yours, Mike.