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 305ECC3DA4A for ; Fri, 16 Aug 2024 11:56:04 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id BC0136B02B2; Fri, 16 Aug 2024 07:56:03 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id B2C4A8D0078; Fri, 16 Aug 2024 07:56:03 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 9C3338D0075; Fri, 16 Aug 2024 07:56:03 -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 7D2BA6B02B2 for ; Fri, 16 Aug 2024 07:56:03 -0400 (EDT) Received: from smtpin22.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 3116EC1AC0 for ; Fri, 16 Aug 2024 11:56:03 +0000 (UTC) X-FDA: 82457955006.22.D1EA428 Received: from szxga08-in.huawei.com (szxga08-in.huawei.com [45.249.212.255]) by imf07.hostedemail.com (Postfix) with ESMTP id A048340015 for ; Fri, 16 Aug 2024 11:56:00 +0000 (UTC) Authentication-Results: imf07.hostedemail.com; dkim=none; spf=pass (imf07.hostedemail.com: domain of linyunsheng@huawei.com designates 45.249.212.255 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=1723809324; 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=KUhLe4Hx4vuKwISnli1x+kiSdW75SbUiX6WqjcHe6Gs=; b=tCyztEpqoETBm6++azTno2e6ieB/zeQz2vNZtYOJUCmJPhIajkofAQshEpjF8/LXT5WRK4 jB1SOxMPTJ+LlgqHdjFF7I0pmcalsr3/D9bbFNBlHyYFxdsI76oCALWkr7OsQ3hdgyi3QY 5ccdOYx95PnzCHt7y2WgTIN7vTURsFk= ARC-Authentication-Results: i=1; imf07.hostedemail.com; dkim=none; spf=pass (imf07.hostedemail.com: domain of linyunsheng@huawei.com designates 45.249.212.255 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=1723809324; a=rsa-sha256; cv=none; b=v20f1u5QUglagYydX2poTD3XWOlJ37pSVb2AxBWPRdm8iqNCWIMWcKcmdUeS2R3gVpE8T6 6UWjACShz2ikhwI9TYUif0ivp3ISpGdQcCLLRkiOE0ImDKbgPVwatqcwnln+Dx6HR3zq3T JcW0pZt31OJnN3N7rbNTTcsvb/KQ8os= Received: from mail.maildlp.com (unknown [172.19.88.105]) by szxga08-in.huawei.com (SkyGuard) with ESMTP id 4WlgRJ4L9Pz1T7Mq; Fri, 16 Aug 2024 19:55:24 +0800 (CST) Received: from dggpemf200006.china.huawei.com (unknown [7.185.36.61]) by mail.maildlp.com (Postfix) with ESMTPS id 0F51F140137; Fri, 16 Aug 2024 19:55:57 +0800 (CST) Received: from [10.67.120.129] (10.67.120.129) by dggpemf200006.china.huawei.com (7.185.36.61) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.11; Fri, 16 Aug 2024 19:55:56 +0800 Message-ID: <1a6aab37-2783-45a2-8edd-0990b211ac2d@huawei.com> Date: Fri, 16 Aug 2024 19:55:56 +0800 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH net-next v13 07/14] mm: page_frag: reuse existing space for 'size' and 'pfmemalloc' To: Alexander Duyck CC: , , , , , Andrew Morton , References: <20240808123714.462740-1-linyunsheng@huawei.com> <20240808123714.462740-8-linyunsheng@huawei.com> <0002cde37fcead62813006ab9516c5b2fdbf113a.camel@gmail.com> Content-Language: en-US From: Yunsheng Lin In-Reply-To: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Originating-IP: [10.67.120.129] X-ClientProxiedBy: dggems701-chm.china.huawei.com (10.3.19.178) To dggpemf200006.china.huawei.com (7.185.36.61) X-Rspamd-Server: rspam03 X-Rspam-User: X-Rspamd-Queue-Id: A048340015 X-Stat-Signature: 4ygt4witm4dwz1q7onnwr1x1tfn81ze3 X-HE-Tag: 1723809360-670003 X-HE-Meta: U2FsdGVkX18iMJ6G2rkCEGX3r2WacketYraxK4xKmajLQ4clKju1XeDG26GtQ9MNvZCnheGTXjEoOXDpIfw97ry4zrKRwaCEyNsjipMwx+rjcKkX+ETHXsBP+sDBsU0Q1+q/jSDafHX6l5SAokc9UxbFa+AS6AZlZ9JE+jbDfpQEweJqD1aN8GmVcwNQNMdiQPKSF9MLkRMpY7AbB5+LeKYo1UnPlcKoV1Y8h0gJ0I2WKzEyfcHPwBDwka0uWoa9MP+LlQfY7lwJRO7WHibqLbt5w9aLl+vw9lID2TMMCKYD8MH+0X8QLV+JB+XGMsQ5RLr1LnlQHEcNsXEtxDGuCubEG8yr5/SAZx3xFEUQ7W7lzycI7K7oZSMP7abBrpHFhiYwYVXiqPxcHFLSplotU+SIZInMqOw/CQ3dAwV4qjQkZ+RsdmidRTGf9UFgVqf2tjkHZ3lhMg79BrlKZRxd/E8qTR4JdPK5slAFKOgQ1NDRe5dLIPz2jzXH8YYPVst+fDsw9bEy2QNGdSpB+XBoLQgyhcDgBON0xTcoiSTdBV0QIFOFwJoy396DsFEtq3O8j8P1q2hzPwQ8Du37avDgv+Y+mZAEFfsoF6NdtLe3uYhIFWO3wRFZ/BkGZRJWBy/0/kCWaDociA46fI9BxGW7NjeoQQdO31NckszYzNWTtiEiQYOSeCjrb1kmonqXhf0cnR/JfkaNDjxmV41JwrlARlWzf341INYm7nhaf1nDLPPAOCu++LJgpuMwZakMWKEpqt9KC0qSXrh1qmOBlRQkwMZn3lxaYBDuzu5fqqT2bqM3QAigRG7zSt58CW4eN7Q8UMqXiOAFxqOdo7MawvWcJLORObD3zfCa92gj0u6CaGFeqPbnObqTUHq7iWxbo6/Wl7WYQYKVdau81txkZSr3RGmVzLguzajlkodEpW0FhymOSza1TKpkoWK5bVyjtrj/CWSLri2WdsgFiIEk3XO VjQ9eEGK nAAK1v9q5Wr0aT94O6NPvrwpafMP57wdby/t3349J4nfUP0y12JJX8kJ1A8vwB+wVoWXBmg5zzedxHXcC1nqFmSnbpCZgAu9PfyBuArid4gVRNkDQ5FawBOrHZVGcyfIiRub+b4OmyNjDOo4Pc7lt2gJYsXxXnrpJj+4vmJlaIqLgouK5GQw3pL5+7moEV0SqUxDhQM1r3LMA1HU0Fb9lcSO3noSX8/knzjDC31sPUleT4jnZpnPUXbupsadWb0lDiu1uUdtbLezt4f7d0iekaWDqH5yYAXXV2w31OhvGtVY400mNMp5tuiaN+b5VJdEewYMdm979r7kngMYPbhEYg10KgBg0/+1GpMIngrG+H7exEP4= 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/8/15 23:03, Alexander Duyck wrote: > On Wed, Aug 14, 2024 at 8:10 PM Yunsheng Lin wrote: >> >> On 2024/8/15 0:13, Alexander H Duyck wrote: >>> On Thu, 2024-08-08 at 20:37 +0800, Yunsheng Lin wrote: >>>> Currently there is one 'struct page_frag' for every 'struct >>>> sock' and 'struct task_struct', we are about to replace the >>>> 'struct page_frag' with 'struct page_frag_cache' for them. >>>> Before begin the replacing, we need to ensure the size of >>>> 'struct page_frag_cache' is not bigger than the size of >>>> 'struct page_frag', as there may be tens of thousands of >>>> 'struct sock' and 'struct task_struct' instances in the >>>> system. >>>> >>>> By or'ing the page order & pfmemalloc with lower bits of >>>> 'va' instead of using 'u16' or 'u32' for page size and 'u8' >>>> for pfmemalloc, we are able to avoid 3 or 5 bytes space waste. >>>> And page address & pfmemalloc & order is unchanged for the >>>> same page in the same 'page_frag_cache' instance, it makes >>>> sense to fit them together. >>>> >>>> After this patch, the size of 'struct page_frag_cache' should be >>>> the same as the size of 'struct page_frag'. >>>> >>>> CC: Alexander Duyck >>>> Signed-off-by: Yunsheng Lin >>>> --- >>>> include/linux/mm_types_task.h | 16 +++++----- >>>> include/linux/page_frag_cache.h | 52 +++++++++++++++++++++++++++++++-- >>>> mm/page_frag_cache.c | 49 +++++++++++++++++-------------- >>>> 3 files changed, 85 insertions(+), 32 deletions(-) >>>> >>>> diff --git a/include/linux/mm_types_task.h b/include/linux/mm_types_task.h >>>> index b1c54b2b9308..f2610112a642 100644 >>>> --- a/include/linux/mm_types_task.h >>>> +++ b/include/linux/mm_types_task.h >>>> @@ -50,18 +50,18 @@ struct page_frag { >>>> #define PAGE_FRAG_CACHE_MAX_SIZE __ALIGN_MASK(32768, ~PAGE_MASK) >>>> #define PAGE_FRAG_CACHE_MAX_ORDER get_order(PAGE_FRAG_CACHE_MAX_SIZE) >>>> struct page_frag_cache { >>>> - void *va; >>>> -#if (PAGE_SIZE < PAGE_FRAG_CACHE_MAX_SIZE) >>>> + /* encoded_va consists of the virtual address, pfmemalloc bit and order >>>> + * of a page. >>>> + */ >>>> + unsigned long encoded_va; >>>> + >>> >>> Rather than calling this an "encoded_va" we might want to call this an >>> "encoded_page" as that would be closer to what we are actually working >>> with. We are just using the virtual address as the page pointer instead >>> of the page struct itself since we need quicker access to the virtual >>> address than we do the page struct. >> >> Calling it "encoded_page" seems confusing enough when calling virt_to_page() >> with "encoded_page" when virt_to_page() is expecting a 'va', no? > > It makes about as much sense as calling it an "encoded_va". What you > have is essentially a packed page struct that contains the virtual > address, pfmemalloc flag, and order. So if you want you could call it > "packed_page" too I suppose. Basically this isn't a valid virtual > address it is a page pointer with some extra metadata packed in. I think we are all argeed that is not a valid virtual address by adding the 'encoded_' part. I am not really sure if "encoded_page" or "packed_page" is better than 'encoded_va' here, as there is no 'page pointer' that is implied by "encoded_page" or "packed_page" here. For 'encoded_va', at least there is 'virtual address' that is implied by 'encoded_va', and that 'virtual address' just happen to be page pointer. Yes, you may say the 'pfmemalloc flag and order' part is about page, not about 'va', I guess there is trade-off we need to make here if there is not a perfect name for it and 'va' does occupy most bits of 'encoded_va'.