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 ACD12C46CD2 for ; Tue, 9 Jan 2024 15:38:26 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 352616B007D; Tue, 9 Jan 2024 10:38:26 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 3021D6B007E; Tue, 9 Jan 2024 10:38:26 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1C8AE6B0080; Tue, 9 Jan 2024 10:38:26 -0500 (EST) 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 0A0266B007D for ; Tue, 9 Jan 2024 10:38:26 -0500 (EST) Received: from smtpin25.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id CD17640365 for ; Tue, 9 Jan 2024 15:38:25 +0000 (UTC) X-FDA: 81660179370.25.5858A14 Received: from mail-pj1-f44.google.com (mail-pj1-f44.google.com [209.85.216.44]) by imf21.hostedemail.com (Postfix) with ESMTP id 02F7D1C0008 for ; Tue, 9 Jan 2024 15:38:23 +0000 (UTC) Authentication-Results: imf21.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=KS4B9CNM; spf=pass (imf21.hostedemail.com: domain of alexander.duyck@gmail.com designates 209.85.216.44 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=1704814704; 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=WczyQ1l8jHhZlEcIGinjqLaLiGU6nueDfrDaoUhkza8=; b=MMr+Fu1FLXSuYRxk4D6V1IqYstshjpbHV4x/j0fCvvwqoA6ncJUefmj188kZ7GrunWqdE0 HpFGMlhL+6IS4XudEtmBIucrab4mRlbVYomBvuFfouhuL/PAT28jiqhB9m3OM4w19MiQCn zp1BDqn6bpRfHmSwE2e6yGKuNv6EbXo= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1704814704; a=rsa-sha256; cv=none; b=cMmGUEVkFxzNGHFTWu+m8xMgksVZ44ZaEX9q4x0A0snS2sUKR0sPO8juDbPJs+AzEkts19 iZ+gS6FXzzav8nMq75BnQjS/JUBLQc9nn5qpqPKTFiG5Q+J1qqTFYFWN9m14fXOve3BiBa Z1bShfs3fCiHfLBKPA8OxrdlAuf3gDw= ARC-Authentication-Results: i=1; imf21.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=KS4B9CNM; spf=pass (imf21.hostedemail.com: domain of alexander.duyck@gmail.com designates 209.85.216.44 as permitted sender) smtp.mailfrom=alexander.duyck@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-pj1-f44.google.com with SMTP id 98e67ed59e1d1-28d2be70358so1535374a91.0 for ; Tue, 09 Jan 2024 07:38:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1704814703; x=1705419503; 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=WczyQ1l8jHhZlEcIGinjqLaLiGU6nueDfrDaoUhkza8=; b=KS4B9CNMwHyI1zX/YSHthQ1R8D0mfxEiKt9u29nsnuCxYgL3g7W4IKCF51chviLj0N OzwvXKtXI+DHniLZO+m/HnFET+va+vtsFUcqJHCOtfl+ZSAKMPkw9htsVsd5JR5ph58a XCqc3W+fexSpzOXzTW4dk31yYMVHL0I6K/rmTgJ/hYNdKtrIgGLHDTre/91Mfp9MknvQ b/r9je6aUvCo5+WwvVfhqkG/kTVvthllWoIX+EyGk2TWQFOJ39YtJACo+esItmYaDSG9 hnm5Tw33kR0n0ey/grC1qksvaaoTCbQnugv/scZCWyRMWX1JBrVTTOLgLg54uMe1vFq0 l2hw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1704814703; x=1705419503; 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=WczyQ1l8jHhZlEcIGinjqLaLiGU6nueDfrDaoUhkza8=; b=dw6WQM/pmFkMtYAcJiSTaCwaxHEHQ05LaEcGOAPEtK29OAV5Uqs8h0YHnMmdrwoRyT j4mRA97Twqi+sNuSlXLrFKqKjTECBeAX3uWs24EYNKi2Rb7yoh0VM9iT+wBR7xgu2C6J WueYIy3jxf7jCxDXxbgZXUAWaGZosvAoBrA8B3EVzAW8bR/nR1aD1vC8c5umQtIUpV39 3HPchcwypPD1wbWvuEKnZXk4UXpAQeJmbeWn8B/xWk3mfwNemEMuRfY7mq41ql+972qd dy+jkHonilEf7cNcmKZieSdapiK1GdIDcRv9yJeF5jCJQxNZ++nji1GjAh2zUPQzUAtI gb1Q== X-Gm-Message-State: AOJu0YwC27m0wLlsa//y4D9Q/zzzUD/HR0vDtQqF7wakpItVI6BznyiM FCF5upiWFrElWumT5mJEWujtU6rAkeH8tG/vsJg= X-Google-Smtp-Source: AGHT+IHqR/5JV65k1KfF5hME9odf6td4CQBJxUxdK4tDc79VgoizfxPtfCJOhfd0MhXfSkP+QdpawpbmNCQ8m+sKO5A= X-Received: by 2002:a17:90b:364c:b0:28d:7947:1da0 with SMTP id nh12-20020a17090b364c00b0028d79471da0mr1816952pjb.29.1704814702732; Tue, 09 Jan 2024 07:38:22 -0800 (PST) MIME-Version: 1.0 References: <20240103095650.25769-1-linyunsheng@huawei.com> <20240103095650.25769-4-linyunsheng@huawei.com> <74c9a3a1-5204-f79a-95ff-5c108ec6cf2a@huawei.com> In-Reply-To: From: Alexander Duyck Date: Tue, 9 Jan 2024 07:37:46 -0800 Message-ID: Subject: Re: [PATCH net-next 3/6] mm/page_alloc: use initial zero offset for page_frag_alloc_align() To: Yunsheng Lin Cc: 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: 02F7D1C0008 X-Rspam-User: X-Stat-Signature: wkxqiyy1os63uykybcgn67psmeycyced X-Rspamd-Server: rspam03 X-HE-Tag: 1704814703-6675 X-HE-Meta: U2FsdGVkX1/LCzdq2Ojpx4HtaWueCxEMGCxxRM0mPu40NOFXww9lsIVNDKUIwXStKHrpAS+KuiZTMAuKiDbX2IPt8ScAjtVb8XHuW9afqsJ35IK0uQFYnEBgG/CjVxSnOkKGCSTzpXu4je5W46RX82F2JFFGyTsQxNUsCmgOl7V6Q/+89wXM/YJte97421cqcK+vcT8tC8+48PlWvL4tfiNeyDnZc42oglBDThsXqtYmmQnOzsQKkoXGLTlbJgdl12lKBksi3P1dMIOSHy9XOhFwlDIF9W1IhwXyNq6IW4CSX6j8Rw5t+RlgsLE7l4XJfzBJINV+bCGBJbgQBDJWwRtdH1Oau8g0Xh9z0ldI+BJzEdI3r7PcNiO5jFTbxh/hGGOgOIuccViuiTDnxBm5/ZKYrBAhJS4Q7S4/sxgudQhBKWWHUkj8I4gWChd4ggMWGnmYkwmnHsBXzzRxDyobGZjXMFSuws8x0SiiCuI9fQsQ5cCpP1xLYibAn6mNsFll4WkEnFrWn8t6xTnsK5ha4T7QeGVsv9dDTVOeHN5onfx5SNsmidgcJ2bXTCSLiokN0Ae7qG/n925HzDtFlkQ9v8qdqDLrP2ZOZ0DUHuwQXvN0Wo7GnujPaP26RQ2/irw+68UERfMe/yaEDzjrP71FT3frP5zMedUN+oJ1xm37TmUk5sAzQ2vVWJBcZ1Y7ctRwzYir+lhamOi4iD9XKXZrrj5LGbAEOaIMsqnT5lwtOU05JaWFXif8c6O4wzYwInwsbm7LNLHyn7frxQdkvYM1SV4yohHo5ZQjaPn7K38rXf1qv0oZPWI9lqMKjI02W1O+OOd1Kjrd3t02JQrshhQrQoCt06Z+FjImiir32ttd7EHwnypEFsXNltHNkhHN3mQZo66aGJPKpczz1PoNjC1/8/8V0+fD1s5MsvNqpUW0qQ8XL7s5YuetQXmTAOiHP47+D8HrfgU8TTHGK2jyo34 nh2tzH+l pTxx5UHv5KQiuXkoXShz1KtUTWGbA+coXTKs4Px32P76kX3I61dKulKajPoFfaNHWDlbR3xKZoxvrUiHcIwaNPJ7E4ZmHj9ujU2VA/owXS+13OLAG4moHAGvMN+UH2fRrKQ60n/sp+wCS+DD1hzEcqgxTFjxh/d0a+yKiA17JwDSokjS/qyf06OE6wvy4NyAr5qUBUAp/uOuL0LJWSN/f3BCn9A9E5+v4WNs78U7UqB0GtqLjBl2wil/u+dwsfL+58/RtQzBn7zSANkdA485lNSg1rwoIFeyOjnKEzr7QT2VB4E8IJ9p/jGORPzEFI0ERrukdEwamWjC0PokQ3q6tmyg1JYjUMd39UFk/WrEiRJbURcQU1ncocHvzbB+PvbCohKWw4nmwiBVShJ76Zyr5bucIYTlvFc33mk3o4PzU5tqzFf4r6Hx3nrk1AOduzuwyO8G9fa7IOt1QZhw= 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 Tue, Jan 9, 2024 at 3:22=E2=80=AFAM Yunsheng Lin wrote: > > On 2024/1/9 0:25, Alexander Duyck wrote: > > On Mon, Jan 8, 2024 at 12:59=E2=80=AFAM Yunsheng Lin wrote: > > ... > > > > >>> > >>> 2. By starting at the end and working toward zero we can use built in > >>> functionality of the CPU to only have to check and see if our result > >>> would be signed rather than having to load two registers with the > >>> values and then compare them which saves us a few cycles. In addition > >>> it saves us from having to read both the size and the offset for ever= y > >>> page. > >> > >> I suppose the above is ok if we only use the page_frag_alloc*() API to > >> allocate memory for skb->data, not for the frag in skb_shinfo(), as by > >> starting at the end and working toward zero, it means we can not do sk= b > >> coalescing. > >> > >> As page_frag_alloc*() is returning va now, I am assuming most of users > >> is using the API for skb->data, I guess it is ok to drop this patch fo= r > >> now. > >> > >> If we allow page_frag_alloc*() to return struct page, we might need th= is > >> patch to enable coalescing. > > > > I would argue this is not the interface for enabling coalescing. This > > is one of the reasons why this is implemented the way it is. When you > > are aligning fragments you aren't going to be able to coalesce the > > frames anyway as the alignment would push the fragments apart. > > It seems the alignment requirement is the same for the same user of a pag= e_frag > instance, so the aligning does not seem to be a problem for coalescing? I'm a bit confused as to what coalescing you are referring to. If you can provide a link it would be useful. The problem is page_frag is a very generic item and can be generated from a regular page on NICs that can internally reuse the same page instance for multiple buffers. So it is possible to coalesce page frags, however it is very unlikely to be coalescing them in the case of them being used for skb buffers since it would require aligned payloads on the network in order to really make it work without hardware intervention of some sort and on such devices they are likely allocating entire pages instead of page frags for the buffers.