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 C658BC3DA4A for ; Thu, 15 Aug 2024 03:10:57 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 36DBB6B0083; Wed, 14 Aug 2024 23:10:57 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 31DF36B0085; Wed, 14 Aug 2024 23:10:57 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 20D406B0088; Wed, 14 Aug 2024 23:10:57 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 03DD66B0083 for ; Wed, 14 Aug 2024 23:10:56 -0400 (EDT) Received: from smtpin27.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id B2DD3A05A6 for ; Thu, 15 Aug 2024 03:10:56 +0000 (UTC) X-FDA: 82453002912.27.B02B3B5 Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [45.249.212.190]) by imf01.hostedemail.com (Postfix) with ESMTP id 6A8DF4001F for ; Thu, 15 Aug 2024 03:10:53 +0000 (UTC) Authentication-Results: imf01.hostedemail.com; dkim=none; spf=pass (imf01.hostedemail.com: domain of linyunsheng@huawei.com designates 45.249.212.190 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=1723691358; 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=d1E7sS8sL72G/A0PhA2NF60+BisZLLOGOzVBBeWI+g4=; b=L1y5mVdogrNPTPRvJdoJqMAg+RSCZ8R0UkQ/mFV3T3qs/DnI8ymyXsHC7oKp3uuv8VPyEh V72mH0tq4GwRy4BOBEY3B/mWG6imkP3HVLW6Gv97iY+Xz6YgHsY8aBYGyDXqBI2duS/Q34 Es2Wl+sgx/nrW+Awpt1pCizoPW2Y3DY= ARC-Authentication-Results: i=1; imf01.hostedemail.com; dkim=none; spf=pass (imf01.hostedemail.com: domain of linyunsheng@huawei.com designates 45.249.212.190 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=1723691358; a=rsa-sha256; cv=none; b=HY+MTUvfbr6C3N+GieNrz4X9qzYsn53xlXyI+5wvNdobbE0wBLWWfF1nsfTKlAdBXNbjh5 wcn0VSLRg4m0QsesEb+8srkdVzPcgMvJUa+t4PzuKVWkBKsD2q9BPG1vupRPGugkz2+uzr gBlv0aT8pBMOkofQCZij2Zq2jsHop2c= Received: from mail.maildlp.com (unknown [172.19.88.234]) by szxga04-in.huawei.com (SkyGuard) with ESMTP id 4Wkqks15GZz2CmNF; Thu, 15 Aug 2024 11:05:57 +0800 (CST) Received: from dggpemf200006.china.huawei.com (unknown [7.185.36.61]) by mail.maildlp.com (Postfix) with ESMTPS id 0D10814040F; Thu, 15 Aug 2024 11:10:50 +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; Thu, 15 Aug 2024 11:10:49 +0800 Message-ID: Date: Thu, 15 Aug 2024 11:10:49 +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 H 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: <0002cde37fcead62813006ab9516c5b2fdbf113a.camel@gmail.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.67.120.129] X-ClientProxiedBy: dggems706-chm.china.huawei.com (10.3.19.183) To dggpemf200006.china.huawei.com (7.185.36.61) X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 6A8DF4001F X-Stat-Signature: 1ixpt1wee6bi674r93i15mpy5ty9xb1u X-Rspam-User: X-HE-Tag: 1723691453-734582 X-HE-Meta: U2FsdGVkX1/xtKXKQAKjdHtxkPvb7dQ5tRak6+CvXa85SUN6mrueMNwqP9ezcQ/Gp0yXpeiB7xZUX5xCtGX0YzJB8jUi+x80TMSzvCqQFYqCmOiZhAPyEtwfXAn6P9I65scMbmNZB/K5xly//tBAeXG3+i7GhqK5EgEsxOw/2hRaRIoOqiIiGf4CuM6Uf7jB8q+9P12yTvh/pkW2pvnznZUjAlevSng9XlBeWCxCQI6Lop9ePzFoOTZN2etMJamffTHPGHk05VBhDXGZRMgKzoU0m1n+r7geX7GG/OcAn07+MOdajl615eqsw01GRAt5gq36apvu9iJWvhz1vhlPLVoVWcGjDm+fodEEWG0/OrgO6nPgXkLQA5EJwNBPGX2as08RAh37GLrkSrhH/2x/b0SPLu01NcM7PYNvM349rWXgOuawF9Yc5NzEYtMucPrJGdwlKP7+DgnBWPTOY77stDsiITfUzTqjCRUutPNqocizOy3l6E6VCklD8HoChpaSULdWPoV7oJwFFY/ih0ZIXt0DI0ScEaSqIsw7PmzWui9b1FaDZKfewiiGmhA3UYbaAwSEBvXlyPyVcQD2LMZX8t/3iPSQCt5nkId+BWw0UcoIZfOatSro7rzv3oRjXgmY4k1lNiTYzKY9dkpMVMXoOS/K22BBOxOUvzMPiutCB9ud0Qu1RUOVnUgDi3uYJGPY5hMDNONiE+tbHc5J+KKIT8/fwSHNYMpXcxzGBpl+5oiMaAJrpGXsX0XPsm6n2Zciz5v+0y2LUTOg+QGAt1i3VloLHKMOTVDZgrBQy4wof24FaJUk05D+xCPz4XEnNTPKG3NJnJXXaiT/9eiENaTGnJW8KvODK4A7xzj15iYuZE2OyQrvmu03COGHG0JuxiWPd6Hlo88PUQP72OKwV+XgHKKU5RQ68iiWe0LVPMYxd37hhsANBjURYHpFIbUEsOthy8b+Od9RzjvoB2RFE4V COXY5ezx iqd6uIZXFN9sDzzYcOatTIl4N9VPpUWGx0qaMAWONSYP3Xn3G1VkN9lLdzZdJCcNiNQlDWOJjxv0dJbIH9aVR+FZYqp+x9773iJzy0XBpFTypYnvZNelTwCguDWPl2d+8aWFMa9kKKUNqIi+DKXcLZ4LH+pVfjCAPGAp2QDXHSlO+NWo3CuRM+ulPEzNxifYbF4HnA/82cUssvGGCOL2E9+yXJXQVecgYn301yd51kX6SO567ao9RrbVrsKVgtj3pdZFnacFMbv6m6zTH3qVL1EoK+loaAXWwt6sGomnvLHRRGCi0VcohKgN4WrYO5wOH2/a20peD0tKweYHIJp/Q1eGWcw== 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 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? >