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 3DB4CC3DA4B for ; Mon, 15 Jul 2024 17:56:23 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 89A256B0083; Mon, 15 Jul 2024 13:56:22 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 849AE6B0088; Mon, 15 Jul 2024 13:56:22 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 711706B0089; Mon, 15 Jul 2024 13:56:22 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 5210E6B0083 for ; Mon, 15 Jul 2024 13:56:22 -0400 (EDT) Received: from smtpin14.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id E85F61A01B0 for ; Mon, 15 Jul 2024 17:56:21 +0000 (UTC) X-FDA: 82342741362.14.D4AC809 Received: from mail-wr1-f52.google.com (mail-wr1-f52.google.com [209.85.221.52]) by imf16.hostedemail.com (Postfix) with ESMTP id 114BD180020 for ; Mon, 15 Jul 2024 17:56:19 +0000 (UTC) Authentication-Results: imf16.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=MD0hokDw; spf=pass (imf16.hostedemail.com: domain of alexander.duyck@gmail.com designates 209.85.221.52 as permitted sender) smtp.mailfrom=alexander.duyck@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1721066143; 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=/W0anjTUFyhsTzhkYxeiTEp5MjzFJ0+hG8HP5QZjcBU=; b=k+ueiof64NxN4Qz6cxvF8stWxFP4xAiQ3I3ovdHxdp5xAT0ikoiWTAyEwtVsUGNdFC7Yl2 roS4SIzGr2rABS0vYvh/UnsvHe+KCP0LwROIueUjubBU71EGQOtGfvk2f4y5Ii6+CJwPwA Y4I0DI8SNOgVFyc4Mbd+8wEFtBvQyGo= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1721066143; a=rsa-sha256; cv=none; b=pjgcMlQW+X9EvI33tfkusxTEnfT93WFBE7tK2YR//vg7tcbwNJP2VYLKNL8VmNsmXKVpkA z7TGtM4mDO90s1c+hXGLM6Q36EDvspSSa/z2Gf5mtQQOFk2qh3GiymllWBR6uBD3cLYoDD lvdeEFTmaVxHU2Yd6k2xHK/dkoHn0CM= ARC-Authentication-Results: i=1; imf16.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=MD0hokDw; spf=pass (imf16.hostedemail.com: domain of alexander.duyck@gmail.com designates 209.85.221.52 as permitted sender) smtp.mailfrom=alexander.duyck@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-wr1-f52.google.com with SMTP id ffacd0b85a97d-367ab76d5e1so1396604f8f.3 for ; Mon, 15 Jul 2024 10:56:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1721066178; x=1721670978; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=/W0anjTUFyhsTzhkYxeiTEp5MjzFJ0+hG8HP5QZjcBU=; b=MD0hokDw+4qNOIRf/vzVFYbCDLZ7MMw4sArWLfZCT+os4wylHlmRfg5Am4faaY1wuT YhWxwXipj7b94GDmToiJfjPdkKIf+bbwkaTs+iz9zED4RNHT9qLoZa3yJpQMMKvgnbvn WLC+uNPAH4xFsx15YyR9lTfPt9/loVGBzZBRne2e/IXtPvAu04v0T9Lz3YDvNaEW7Epz WjHlyqYLisp6iZysaPyYt0xTpZHUAK19Stzxk0S8UlqkOw7ohjDZdMcS7L4nXe1nqHaC 0GFjKMOhj4AY+33cFSip12cnnlB1fhJ5IPmjvdZfVe6JlrYeXie71pJxzS3Lo6QHSNO1 eC2A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1721066178; x=1721670978; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=/W0anjTUFyhsTzhkYxeiTEp5MjzFJ0+hG8HP5QZjcBU=; b=niqcUhQWjSLz9EkuiQ6Qrvf3Ehp4kv9jNqSZg/7n+/nGMcHu4vmGdbyZFQFyTz/N4J 54aqb/4KAb/BioErYWTpAJUkHwNaTQb6aW1nZRg4C8KyZ6JORKo10gJUyM/GS905Joxv HstbZTgdczwl7MeLtiEYz0XHyujJynKGDgwr3OV2u8w59cXYAwMWLMhiC4HtaWS6LTZU wZGdWuWnhR6lDCgB6lTEGsRGNF7SZsm98rl9y8IhLqFWVSejVLzQlteEmX+4vc9zqAKK NwHbWFlCUk3+5OEwuRKt8wiJbJRBcfDU664C0EkzJYfquiNK1fLkshTyKmWPV2v03a66 GuZw== X-Forwarded-Encrypted: i=1; AJvYcCV+gMDmLExNURMfzCLPta11INHjugC/ww/Xotr5itdrWfaKwDelrJjZMrnTaq0lCGOOrwjIvxdY/0mRwTHRh3m23lg= X-Gm-Message-State: AOJu0Yz+YF0Nf91h1ZeH+84cLjW00h5/QfnSrhwPCbKWVBdq2W+3xY3s FGHmxYoMSmWbFOhe5lgOL3iPhmjuOnkn1UA3uQuhPgliheh1X937uR1YQFVHhQSj6IQNJk9dz+V NBh5lj+bKJdirOFkVmyZrlSHwogY= X-Google-Smtp-Source: AGHT+IFk6VNFCK/xpbOPqFvPPxvE/7ruwrAkwWPKtUxFlAOsZs2IddEppQ2kmqqdXUJPhQwn2bActSLmPnZWrlu9U2Y= X-Received: by 2002:adf:f707:0:b0:367:988d:fb99 with SMTP id ffacd0b85a97d-3682407cfe9mr347686f8f.8.1721066178313; Mon, 15 Jul 2024 10:56:18 -0700 (PDT) MIME-Version: 1.0 References: <20240625135216.47007-1-linyunsheng@huawei.com> <20240625135216.47007-7-linyunsheng@huawei.com> <12a8b9ddbcb2da8431f77c5ec952ccfb2a77b7ec.camel@gmail.com> <808be796-6333-c116-6ecb-95a39f7ad76e@huawei.com> <96b04ebb7f46d73482d5f71213bd800c8195f00d.camel@gmail.com> <5daed410-063b-4d86-b544-d1a85bd86375@huawei.com> <29e8ac53-f7da-4896-8121-2abc25ec2c95@gmail.com> <12ff13d9-1f3d-4c1b-a972-2efb6f247e31@gmail.com> In-Reply-To: <12ff13d9-1f3d-4c1b-a972-2efb6f247e31@gmail.com> From: Alexander Duyck Date: Mon, 15 Jul 2024 10:55:42 -0700 Message-ID: Subject: Re: [PATCH net-next v9 06/13] mm: page_frag: reuse existing space for 'size' and 'pfmemalloc' To: Yunsheng Lin Cc: Yunsheng Lin , davem@davemloft.net, kuba@kernel.org, pabeni@redhat.com, netdev@vger.kernel.org, linux-kernel@vger.kernel.org, Andrew Morton , linux-mm@kvack.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 114BD180020 X-Stat-Signature: waanaji64ksbtt19ikumjxdna4d8qd1w X-Rspamd-Server: rspam09 X-Rspam-User: X-HE-Tag: 1721066179-330712 X-HE-Meta: U2FsdGVkX18gwxdrtXZtIpYXpjW/ev9SGM6hrOMFqvPIVP1si6QJ2ghKS8ZRxpw3Q8D5D2brq2Ll0FY2x/UCr7Qzpb5oqhFMBctwjQbnp6Lu0MR6JcHXHrO2L80xdZyzrZot3imJKgj7e9XyFT99xbeKAzekHG6fdlIq5OyCzonHGPZ/XbyFC/TCWXjmcEU16jAjkAznpbWUTK5gHDbtA7M95I1Qql2MAUCfANESUc1pwMcW1+k4e9BvJR3xnhMxmT5GJvLWLllDE1CWY7riHRDhmd8l314oygJU7dTv4l4CpSo2IYXKLE3vr08h0/RHdvm5rCLE6zv89m1xEzGrrPoTj3q20Vl4iarjjt1few+nTGX/4SAa9TPnN6HxG2R8cTajja8/Ef7r1Xtc67kQrs7zvoSTOVz9DZMY57ZvFq6CMlDuBW/V9DUJh73eqGy3U5lFv6V5sZpurbLBQ6EG42OzcezyUSPgjcDuiIkMskiVgX9mQTYsf5pssdqvi+3eWaDp9D/SXdLp63wRDKAfkU5O7BC9HHDuxGjKv8y/aqil6Hk4XgYsLbRMPLDxN5Qvag9XscjEw09+GQvT6VS4v1gmgUmRfJIM+e9wDcAAPFEkVipoGLZ9umIdFC49AU+wEP+ZVRyMqDtKkRqiAj/IQpGbw9j3RLRWkeRiMeq+/1ubf/HI0VhUMtUffOSTcwq2oZLDORgGnAOYETROgYyT/4zosr44fK87kiw/1eWeIkFfdyp+R0psCt278XQXqXz6PRmSHikSHKEK0q4huwgoPsoq6z7PKB9yUvXi5Ui2BSD1yWaoUbyPtLUMuaQ8zBmoThXQbNF5DhadsNxLT5/SDSpzf7j0HVqb4EvHYn91viWgq+sj1D/lC+bC94iZcLrP41vtKo0B4F3U9Wd3z9/w3a2K8vjVZHJ3hDiDwVqz21jfQfeWW93P+I1FeOwSZCmAwE3I54dNNB8gZQmoMZv pVBWr0a6 Qi3lbll0hBr0Koujo8h0EiLvK4Gffr6ifu+Sg/0HlMe7g298bVqia73LPLgMB3h2MQ9K4Dm1Na9lxrhq+IH6RlW/pell9axvBjCTrz9grJFFbaI3e2CBF3N2Var5tQv6Us4TjkR08nopOGbZWtQPisTGByc8YolIW2nwZJEEIMUXQewhjJ0tgbVXAjD1YFSooKqwIt5Ocei4DAohuYBS/XaQ0ZujzXtGPpGnBpDLOm35RcQct37FDRSqBPY26rK3WrNIEXATdxJ0T1wWZg03M2d0N0r7M2Ew6EopQSzHSBM5/8UL7kPg9hfLG4UzbrPQzAFzVhs+UttwitnQ8qsQJs7G+kubDM8yZ0jFuzxWmfBBYbX4FhVHOrv3/AALiSFZALx10X/1fQUPWFeM= 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 Sat, Jul 13, 2024 at 9:52=E2=80=AFPM Yunsheng Lin wrote: > > On 7/14/2024 12:55 AM, Alexander Duyck wrote: > > ... > > >>>> > >>>> Perhaps the 'remaining' changing in this patch does seems to make th= ings > >>>> harder to discuss. Anyway, it would be more helpful if there is some= pseudo > >>>> code to show the steps of how the above can be done in your mind. > >>> > >>> Basically what you would really need do for all this is: > >>> remaining =3D __ALIGN_KERNEL_MASK(nc->remaining, ~align_mask); > >>> nc->remaining =3D remaining + fragsz; > >>> return encoded_page_address(nc->encoded_va) + size + remaining; > >> > > > > I might have mixed my explanation up a bit. This is assuming remaining > > is a negative value as I mentioned before. > > Let's be more specific about the options here, what you meant is below, > right? Let's say it is option 1 as below: > struct page_frag_cache { > /* encoded_va consists of the virtual address, pfmemalloc bit > and order > * of a page. > */ > unsigned long encoded_va; > > #if (PAGE_SIZE < PAGE_FRAG_CACHE_MAX_SIZE) && (BITS_PER_LONG <=3D 32) > __s16 remaining; > __u16 pagecnt_bias; > #else > __s32 remaining; > __u32 pagecnt_bias; > #endif > }; > > void *__page_frag_alloc_va_align(struct page_frag_cache *nc, > unsigned int fragsz, gfp_t gfp_mask, > unsigned int align_mask) > { > unsigned int size =3D page_frag_cache_page_size(nc->encoded_va); > int remaining; > > remaining =3D __ALIGN_KERNEL_MASK(nc->remaining, ~align_mask); > if (unlikely(remaining + (int)fragsz > 0)) { > if (!__page_frag_cache_refill(nc, gfp_mask)) > return NULL; > > size =3D page_frag_cache_page_size(nc->encoded_va); > > remaining =3D -size; > if (unlikely(remaining + (int)fragsz > 0)) > return NULL; > } > > nc->pagecnt_bias--; > nc->remaining =3D remaining + fragsz; > > return encoded_page_address(nc->encoded_va) + size + remaining; > } > > > And let's say what I am proposing in v10 is option 2 as below: > struct page_frag_cache { > /* encoded_va consists of the virtual address, pfmemalloc bit > and order > * of a page. > */ > unsigned long encoded_va; > > #if (PAGE_SIZE < PAGE_FRAG_CACHE_MAX_SIZE) && (BITS_PER_LONG <=3D 32) > __u16 remaining; > __u16 pagecnt_bias; > #else > __u32 remaining; > __u32 pagecnt_bias; > #endif > }; > > void *__page_frag_alloc_va_align(struct page_frag_cache *nc, > unsigned int fragsz, gfp_t gfp_mask, > unsigned int align_mask) > { > unsigned int size =3D page_frag_cache_page_size(nc->encoded_va); > int aligned_remaining =3D nc->remaining & align_mask; > int remaining =3D aligned_remaining - fragsz; > > if (unlikely(remaining < 0)) { > if (!__page_frag_cache_refill(nc, gfp_mask)) > return NULL; > > size =3D page_frag_cache_page_size(nc->encoded_va); > > aligned_remaining =3D size; > remaining =3D aligned_remaining - fragsz; > if (unlikely(remaining < 0)) > return NULL; > } > > nc->pagecnt_bias--; > nc->remaining =3D remaining; > > return encoded_page_address(nc->encoded_va) + (size - > aligned_remaining); > } > > If the option 1 is not what you have in mind, it would be better to be > more specific about what you have in mind. Option 1 was more or less what I had in mind. > If the option 1 is what you have in mind, it seems both option 1 and > option 2 have the same semantics as my understanding, right? The > question here seems to be what is your perfer option and why? > > I implemented both of them, and the option 1 seems to have a > bigger generated asm size as below: > ./scripts/bloat-o-meter vmlinux_non_neg vmlinux > add/remove: 0/0 grow/shrink: 1/0 up/down: 37/0 (37) > Function old new delta > __page_frag_alloc_va_align 414 451 +37 My big complaint is that it seems option 2 is harder for people to understand and more likely to not be done correctly. In some cases if the performance difference is negligible it is better to go with the more maintainable solution.