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 E679DC25B10 for ; Fri, 10 May 2024 09:48:51 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 735336B00AA; Fri, 10 May 2024 05:48:51 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 6E4E46B00AB; Fri, 10 May 2024 05:48:51 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5ACC96B00AC; Fri, 10 May 2024 05:48:51 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 3CC3E6B00AA for ; Fri, 10 May 2024 05:48:51 -0400 (EDT) Received: from smtpin09.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id B74C31417BE for ; Fri, 10 May 2024 09:48:50 +0000 (UTC) X-FDA: 82102012020.09.E37D469 Received: from szxga02-in.huawei.com (szxga02-in.huawei.com [45.249.212.188]) by imf17.hostedemail.com (Postfix) with ESMTP id 85BBD4001D for ; Fri, 10 May 2024 09:48:47 +0000 (UTC) Authentication-Results: imf17.hostedemail.com; dkim=none; spf=pass (imf17.hostedemail.com: domain of linyunsheng@huawei.com designates 45.249.212.188 as permitted sender) smtp.mailfrom=linyunsheng@huawei.com; dmarc=pass (policy=quarantine) header.from=huawei.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1715334528; 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; bh=Rql/y2sevGNeSzUFYdyUGOojEuggN0exdZYc1iZNklw=; b=C1uoSf2fPduhc4WSEA3YsXAxEu5JtJGySdoTjxppxLnr1UzM/FYqfEZR4ILOe/XW7WCWEh E+4VZz9CW1LRgp+psqA1e+yOvtHkSKwcgcGstzd2KRl5CztaV01PCXsSiApYg7qyI4smNs /fyndkJD/xGdvam/N0/oH/ASxP6R1i0= ARC-Authentication-Results: i=1; imf17.hostedemail.com; dkim=none; spf=pass (imf17.hostedemail.com: domain of linyunsheng@huawei.com designates 45.249.212.188 as permitted sender) smtp.mailfrom=linyunsheng@huawei.com; dmarc=pass (policy=quarantine) header.from=huawei.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1715334528; a=rsa-sha256; cv=none; b=sRX6Fnf40GtBjy6rW2Rph0BTZesobM0PKVPoDGAe+9QFlVZAqMLSK9G4YmSljcDYJGW9ig aCqVZ2AkdatDsgsrQrdX7M0sa1TZy6UorE5UB5R7oAKlJFQw+8rdD6/QCEspQeAMnMEb5L A/LPjxe+eX2nOAsFHmkBGLVah2uIJLU= Received: from mail.maildlp.com (unknown [172.19.88.194]) by szxga02-in.huawei.com (SkyGuard) with ESMTP id 4VbP9s42bYzfbh9; Fri, 10 May 2024 17:44:49 +0800 (CST) Received: from dggpemm500005.china.huawei.com (unknown [7.185.36.74]) by mail.maildlp.com (Postfix) with ESMTPS id 445551400E3; Fri, 10 May 2024 17:48:43 +0800 (CST) Received: from [10.69.30.204] (10.69.30.204) by dggpemm500005.china.huawei.com (7.185.36.74) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2507.35; Fri, 10 May 2024 17:48:43 +0800 Subject: Re: [PATCH net-next v3 12/13] mm: page_frag: update documentation for page_frag To: Randy Dunlap , , , CC: , , Alexander Duyck , Jonathan Corbet , Andrew Morton , , References: <20240508133408.54708-1-linyunsheng@huawei.com> <20240508133408.54708-13-linyunsheng@huawei.com> <0ac5219b-b756-4a8d-ba31-21601eb1e7f4@infradead.org> From: Yunsheng Lin Message-ID: <28447d18-dc61-3652-f572-617e718c8bd5@huawei.com> Date: Fri, 10 May 2024 17:48:42 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.0 MIME-Version: 1.0 In-Reply-To: <0ac5219b-b756-4a8d-ba31-21601eb1e7f4@infradead.org> Content-Type: text/plain; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [10.69.30.204] X-ClientProxiedBy: dggems704-chm.china.huawei.com (10.3.19.181) To dggpemm500005.china.huawei.com (7.185.36.74) X-Stat-Signature: dzzhc5d3o3w6gdpnbacskjkfdctrobb4 X-Rspam-User: X-Rspamd-Queue-Id: 85BBD4001D X-Rspamd-Server: rspam05 X-HE-Tag: 1715334527-659696 X-HE-Meta: U2FsdGVkX1/ecs7SXFkHfmIRqELIgJ6r2n3PCN4Hk8fCqNDCoOgONlQCkzbog317tNVmi3dsDuhZjaUJkJfJdnV052K7s2Q++QALufqDltfc+ifIhcmg1OLONU6LtE0kDAOmdwLBLFZYceNCCgVvpHwpUT3LeY2KcRMCioKOg47AByUvf3evpE8ZjAI7jbE3VaFUN4hPydGLhn9CO7hTgSBpb/TyMo3zXZ1KdY048+zV0e2i1Do4HjYPZip8ScoJKnRl0iHrRln1dOhWIAkHXbNPKfRKO66KPNdUySW/zHVpAre2kWJz3eqZnN/Abqo0Tc3PZGeoOi3sMSXpSzd6bUasXttX6P/x9/72Jv+Un0B8laOw3SxinMwZ1/PmkcW6bfz9c1Gi5suxocdK4pHIyQuKFEsRZ0rBRV4c2j6/wjCJrZZXnaKgqPNn+t4vadBTjI2ABj9sZ9anIf+bY+2kZ5x4gYpIcNissEvCJGKsGV0jm3TWlVF3IHX+T2WAw8kWA65Qy8WXFc0qwxmQ/HqK8Ir1BzrBUbg6MjCucomD6C7VyfUktVvKzkztP7dh2GqNqOFKjHlf/z/Bd1AQcB1vNu5PJ3vpLgYe6K17h5YUtbVsOkm+tIDM08r+K2YLcO3Bffh0Uas9arDeLn4gkQpyjHwKduUKGvGP9pHYuxXrPcMV9cAHOxwRO42ipp2QAG6aK0tvheqfvyE8UVwFPwitl7CFCDjaEsmX4gawEJKgyu9140s24CiNDq3rsS1hxxEVecYkCn+ZfupGM45RHdy2HeZ0TVVQnuHP4Wm24P2xC/quutQNH/HIZ0CzYQtGumjwlc73BUoL9q0EIZpr+wGJUJy1KlQVFddHWsSx/Z5n/SltDwh0h47BxH7M+JkefnAbF2l2E431SL1jTl79EEriCXmr0k5tMObgekTTDBFRE4N6tyAfr//xi/oDJbpvEzn7mJwX1K5j3FM6nAf+sap Cvfr2BcY aDYiNN5adia3fXcwnvYpmIlBNgjyPi2U5RVW0koSt+tYdfxdOuZkO7b9s/z5cSq2Im1c9JZ0MtapfAsfAUyrNbdJE5S8QKSB2874tZ15Kyj6khrtm2mxBaNmV98GRacrG07mbk73jTvElkR9045d6s9V2QRXuTWeADtHgJ0ILGvcZa1Xdz8IrB5KPswAz4VbWD1tAc2tOZ9lcmipfDseYwtE2Xmb3BXAo0SvFxCfo/KgkOw50CkGBBHlvg/rWAzh5LWaHIJoAkhWfXypOPRTFJAo36GcX6t8e7jSGK5Wd0rhEU7o= 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 2024/5/9 8:44, Randy Dunlap wrote: > > > On 5/8/24 6:34 AM, Yunsheng Lin wrote: >> Update documentation about design, implementation and API usages >> for page_frag. >> >> CC: Alexander Duyck >> Signed-off-by: Yunsheng Lin >> --- >> Documentation/mm/page_frags.rst | 156 +++++++++++++++++++++++++++++++- >> include/linux/page_frag_cache.h | 96 ++++++++++++++++++++ >> mm/page_frag_cache.c | 65 ++++++++++++- >> 3 files changed, 314 insertions(+), 3 deletions(-) >> >> diff --git a/Documentation/mm/page_frags.rst b/Documentation/mm/page_frags.rst >> index 503ca6cdb804..9c25c0fd81f0 100644 >> --- a/Documentation/mm/page_frags.rst >> +++ b/Documentation/mm/page_frags.rst >> @@ -1,3 +1,5 @@ >> +.. SPDX-License-Identifier: GPL-2.0 >> + >> ============== >> Page fragments >> ============== >> @@ -40,4 +42,156 @@ page via a single call. The advantage to doing this is that it allows for >> cleaning up the multiple references that were added to a page in order to >> avoid calling get_page per allocation. >> >> -Alexander Duyck, Nov 29, 2016. >> + >> +Architecture overview >> +===================== >> + >> +.. code-block:: none >> + >> + +----------------------+ >> + | page_frag API caller | >> + +----------------------+ >> + ^ >> + | >> + | >> + | >> + v >> + +------------------------------------------------+ >> + | request page fragment | >> + +------------------------------------------------+ >> + ^ ^ ^ >> + | | Cache not enough | >> + | Cache empty v | >> + | +-----------------+ | >> + | | drain old cache | | >> + | +-----------------+ | >> + | ^ | >> + | | | >> + v v | >> + +----------------------------------+ | >> + | refill cache with order 3 page | | >> + +----------------------------------+ | >> + ^ ^ | >> + | | | >> + | | Refill failed | >> + | | | Cache is enough >> + | | | >> + | v | >> + | +----------------------------------+ | >> + | | refill cache with order 0 page | | >> + | +----------------------------------+ | >> + | ^ | >> + | Refill succeed | | >> + | | Refill succeed | >> + | | | >> + v v v >> + +------------------------------------------------+ >> + | allocate fragment from cache | >> + +------------------------------------------------+ >> + >> +API interface >> +============= >> +As the design and implementation of page_frag API implies, the allocation side >> +does not allow concurrent calling. Instead it is assumed that the caller must >> +ensure there is not concurrent alloc calling to the same page_frag_cache >> +instance by using its own lock or rely on some lockless guarantee like NAPI >> +softirq. >> + >> +Depending on different aligning requirement, the page_frag API caller may call >> +page_frag_alloc*_align*() to ensure the returned virtual address or offset of >> +the page is aligned according to the 'align/alignment' parameter. Note the size >> +of the allocated fragment is not aligned, the caller need to provide a aligned > > needs to provide an aligned > >> +fragsz if there is a alignment requirement for the size of the fragment. > > an alignment Will update them accordingly, thanks for the review.