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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 9EB15EB64DA for ; Sat, 17 Jun 2023 12:20:31 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:Date: Message-ID:From:References:Cc:To:Subject:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Owner; bh=ZSdXl1FlXRL64o9MtcaKxYIBMgb5OUzUVBmq2agoOLE=; b=OVYvug3jtQmev8DsKhgfBpOcI6 R2qFhAqWd8S3E12JnL5NiprQFyAMbaREqvgiraorrU6O3HKZklnTiz5FMaSMsX8X/nzmQdAcsrGjt A2zm+lO+ALJr41ufw3sAfupJ/gCVB3Fz1/HIhrufH1vDJ0KeamDrlfyKMK8RHdD4I/pnyIERD0rp5 niuWex80rqs61bYY204/qzkyplsWTIitnq4y4nudL0jt+D8Nz/h/Ashe+kWBF9BP27hYsmryE/8kp Gps/JKUIHtQRi21ks9kID/vCrannsV/Dku5XHPJMHmR+xgEeXJGdqjbgmICPzyd6HinZ20cyWqNMH W30rPiHA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1qAUuS-003Zmj-0A; Sat, 17 Jun 2023 12:20:04 +0000 Received: from mail-pf1-x443.google.com ([2607:f8b0:4864:20::443]) by bombadil.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1qAUuO-003Zlj-1l; Sat, 17 Jun 2023 12:20:01 +0000 Received: by mail-pf1-x443.google.com with SMTP id d2e1a72fcca58-666e6ecb52dso578523b3a.2; Sat, 17 Jun 2023 05:19:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1687004398; x=1689596398; h=content-transfer-encoding:content-language:in-reply-to:mime-version :user-agent:date:message-id:from:references:cc:to:subject:from:to:cc :subject:date:message-id:reply-to; bh=SZNkQ1oz0wZkelNmFj+FIBMQj5UYWBe8cBOvWPEMfvc=; b=BAMvCicwBQQ11o6+oWBt4ZEq6GvmXZEse1xxW5+iHLo8nWGPmm27b7MF+yMGRX7ILH DJbQFZTMsyRQU6qLU6V7R7ZJH+FjZOjPbqqXoRtmrw1KAH1QmTCea9FXYqbkAi2UOVUg h3iHNeq19AT9OPkC40ft4+ZzG3ShFvoOiA8l60suenn5+NXIBlznglNzWN5cgbwHlae5 xb0hKEbeqKIx6A6hdZhyrunV0jUicHZJpDuewuPK92m27aQ8Yrr8O5CnMEV4i7Erk1/P hJBqy0Kywv5Tol9v1dBDaZZNvC+KyI6M+VUNHSLCTh5dQUjnDSx/1w/4OG/W+Dwu4XZa SBzA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1687004398; x=1689596398; h=content-transfer-encoding:content-language:in-reply-to:mime-version :user-agent:date:message-id:from:references:cc:to:subject :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=SZNkQ1oz0wZkelNmFj+FIBMQj5UYWBe8cBOvWPEMfvc=; b=Kx4OQ2NoFpfTMXmyfNqCfDVF/JS6Key4Iq/pktfsycc1UwLDeOpmNYGo1oH2ME5oGr 5Lp6WQyX5OCIrBuNTmluJ5QnxJgflntB3Qe2x5sV259ggE/k8By4U0I8EabOMY3hbdQj AuZpM8S/2QwLtKe60R938HOI2Xoa8ncKbkfJG0Ym9jQ9CEs10D2CB5Osn6HT2AxgaFxx vlPBsAdGDtDY6CmEIT+tS/sDEAUPG61LmbMkAx2jj4GCVKoXvw14WVWIvvQuodPxyF3N wU4oS46pwTmm03N4POGB8Bn4X9n7+yQZ5XSRiJGEUSMiJg6gpIqHgjUWEEC1kcEs47a1 dbVg== X-Gm-Message-State: AC+VfDwX8nz6Tsq7BmDh9vewW2FfaEtTzyr0kJ9KRYEmkPRTuUi6f5BK RAcmWX1LFLarpjwEucjF7Z9of1g424j8fS19Ygw= X-Google-Smtp-Source: ACHHUZ4o+kTjugYQDUVwiuYy+KjqUZTvsrgkBJ1P55VRXZ306mPOj/HQaNIlGq85TdSLZ1h5Z+ubTg== X-Received: by 2002:a05:6a00:1881:b0:668:6eed:7c1e with SMTP id x1-20020a056a00188100b006686eed7c1emr133489pfh.10.1687004398336; Sat, 17 Jun 2023 05:19:58 -0700 (PDT) Received: from ?IPv6:2409:8a55:301b:e120:18ac:7176:4598:6838? ([2409:8a55:301b:e120:18ac:7176:4598:6838]) by smtp.gmail.com with ESMTPSA id x23-20020aa793b7000000b00666b6dc10desm2508817pff.56.2023.06.17.05.19.51 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 17 Jun 2023 05:19:57 -0700 (PDT) Subject: Re: [PATCH net-next v4 4/5] page_pool: remove PP_FLAG_PAGE_FRAG flag To: Alexander Duyck , Yunsheng Lin Cc: Jakub Kicinski , davem@davemloft.net, pabeni@redhat.com, netdev@vger.kernel.org, linux-kernel@vger.kernel.org, Lorenzo Bianconi , Yisen Zhuang , Salil Mehta , Eric Dumazet , Sunil Goutham , Geetha sowjanya , Subbaraya Sundeep , hariprasad , Saeed Mahameed , Leon Romanovsky , Felix Fietkau , Ryder Lee , Shayne Chen , Sean Wang , Kalle Valo , Matthias Brugger , AngeloGioacchino Del Regno , Jesper Dangaard Brouer , Ilias Apalodimas , linux-rdma@vger.kernel.org, linux-wireless@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-mediatek@lists.infradead.org References: <20230612130256.4572-1-linyunsheng@huawei.com> <20230612130256.4572-5-linyunsheng@huawei.com> <20230614101954.30112d6e@kernel.org> <8c544cd9-00a3-2f17-bd04-13ca99136750@huawei.com> <20230615095100.35c5eb10@kernel.org> <908b8b17-f942-f909-61e6-276df52a5ad5@huawei.com> From: Yunsheng Lin Message-ID: Date: Sat, 17 Jun 2023 20:19:46 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.2 MIME-Version: 1.0 In-Reply-To: Content-Language: en-GB X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20230617_052000_615143_37302B97 X-CRM114-Status: GOOD ( 22.64 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On 2023/6/16 23:01, Alexander Duyck wrote: ... >>> Actually that would be a really good direction for this patch set to >>> look at going into. Rather than having us always allocate a "page" it >>> would make sense for most drivers to allocate a 4K fragment or the >>> like in the case that the base page size is larger than 4K. That might >>> be a good use case to justify doing away with the standard page pool >>> page and look at making them all fragmented. >> >> I am not sure if I understand the above, isn't the frag API able to >> support allocating a 4K fragment when base page size is larger than >> 4K before or after this patch? what more do we need to do? > > I'm not talking about the frag API. I am talking about the > non-fragmented case. Right now standard page_pool will allocate an > order 0 page. So if a driver is using just pages expecting 4K pages > that isn't true on these ARM or PowerPC systems where the page size is > larger than 4K. > > For a bit of historical reference on igb/ixgbe they had a known issue > where they would potentially run a system out of memory when page size > was larger than 4K. I had originally implemented things with just the > refcounting hack and at the time it worked great on systems with 4K > pages. However on a PowerPC it would trigger OOM errors because they > could run with 64K pages. To fix that I started adding all the > PAGE_SIZE checks in the driver and moved over to a striping model for > those that would free the page when it reached the end in order to > force it to free the page and make better use of the available memory. Isn't the page_pool_alloc() or page_pool_alloc_frag() API also solve the above problem? I think what you really want is another layer of subdividing support in the driver on top of the above, right? _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel