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 7BE57C4345F for ; Thu, 18 Apr 2024 21:56:37 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id DDF426B0098; Thu, 18 Apr 2024 17:56:36 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id D900A6B0099; Thu, 18 Apr 2024 17:56:36 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C568B6B009E; Thu, 18 Apr 2024 17:56:36 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id A7C506B0098 for ; Thu, 18 Apr 2024 17:56:36 -0400 (EDT) Received: from smtpin18.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 4F3C3160407 for ; Thu, 18 Apr 2024 21:56:36 +0000 (UTC) X-FDA: 82024012392.18.BC223FD Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf04.hostedemail.com (Postfix) with ESMTP id 2E8EF4000F for ; Thu, 18 Apr 2024 21:56:29 +0000 (UTC) Authentication-Results: imf04.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=UiHfUv63; spf=none (imf04.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1713477392; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=NKHq3RRb9DZOry1fX1WTmEfYYxoxdlJDDrBtepAjKaI=; b=5JYClBvwDSedgatYNCDeGYmOdKA/BHER5oe77KtXm6MdYv+1+68nOAaK/EUpUB5sqXUi7I 9vUxVDklkDMVcseQE4mPeSiS4+Xj07AIIOw7lBMYuO4rMN1k0llW//Xx3zYcwe4nuJ9lVh BDlFDy2euqZlVY/LgMYYHYUtKFO/Z8A= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1713477392; a=rsa-sha256; cv=none; b=rv1ZlSHLAi9W1IzAhrwQeuV9iur0Dc3r80cLZUXns0Sb9ECNvxmGdKwZ7DN4AXuURn7Kgm yIre/XksW5l+eDGPFhTpoAw0miGyKFnDHJ6kv1sWJGDYFYdk2JVzBY8xWu6Z8sjOcyqRnW vc7+Fhxdmocwkhk0SCutY0quYCCfq7k= ARC-Authentication-Results: i=1; imf04.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=UiHfUv63; spf=none (imf04.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org; dmarc=none DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=NKHq3RRb9DZOry1fX1WTmEfYYxoxdlJDDrBtepAjKaI=; b=UiHfUv63WoWeuvhfBqP8BLCR42 r9wM/6ZfekDEB49NOf2VW/S5/UTloS37YkTi0QiFpimPwcr6e7ktBu2FBt4LC8UINt4aTJ8rqEryn vsXSz/9x0iH7gawFtz/CrLMGRoHe24MrVnJQBdW/axtDisDqmbQhucPdx8q5E//lovEn32Y9XCm6m OFmlpeXfbaCVfFyzSj9T8DmLYSWkAkmEr+jA5K2EoNmWMLVCLeXlkDdMBXd9pcPD1B5qUY8zDx6Ei 6lRRqTV/45CusrP8/BY+eSqv46KoE2x0yxD/SR1iM1ZNdUkzSrKNIQayWghtMMDRDWkwA+lT2WgS0 yLm79o0g==; Received: from willy by casper.infradead.org with local (Exim 4.97.1 #2 (Red Hat Linux)) id 1rxZjt-00000006FH2-0nmU; Thu, 18 Apr 2024 21:56:17 +0000 Date: Thu, 18 Apr 2024 22:56:17 +0100 From: Matthew Wilcox To: Jesper Dangaard Brouer Cc: Xuan Zhuo , Jason Wang , virtualization@lists.linux.dev, "Michael S. Tsirkin" , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , netdev@vger.kernel.org, Linux-MM , Ilias Apalodimas , Mel Gorman Subject: Re: [PATCH vhost 3/6] virtio_net: replace private by pp struct inside page Message-ID: References: <1713146919.8867755-1-xuanzhuo@linux.alibaba.com> <1713170201.06163-2-xuanzhuo@linux.alibaba.com> <1713171554.2423792-1-xuanzhuo@linux.alibaba.com> <1713317444.7698638-1-xuanzhuo@linux.alibaba.com> <1713342055.436048-1-xuanzhuo@linux.alibaba.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Stat-Signature: 9s6crt88ytuaobwzrnysh34bhg4won63 X-Rspamd-Queue-Id: 2E8EF4000F X-Rspamd-Server: rspam06 X-Rspam-User: X-HE-Tag: 1713477389-849365 X-HE-Meta: U2FsdGVkX1/CT3vDy5EGWfDpjKL6iU3QEydgkqLR6TtyBw7bxWHaG+hVHP3N2oINHK0Qsh8PdfkImDx+aS16yi+QDJ6k5AArUpDdydWCWlh966w/QVaoOBNro1PkNwrJy+n69XU70fG3rV1ESrmHecxsDaRyoySWwA8keKSqWSq6W3Yk7WzRed7a/K48NPkJOpVJjLlFykKp+DDw5DsTh/BJMMIkxXuQgrT0FFBdlAPl9DSxbnWrRv45cmyc8nBK3d/BJmgVacZgmmMRbsI2OXrzoE1zD08fEECubbKFXV4xWxCXL2XXiZABlula7vTxPLxBOUW+X+I757oEd1H0dzg7O7bU0d+6FfjA1Z/ejq3UjR+tby2zDYg5xZG3l7S01rE6zKKm+/oG2SGNhUzJP5cXZQqEy6UA8DC5APSTzNY4xEaayJnlJw7g9miMml7lYXe86yy8VFmsgICoDHtrW1JKXfjBQ9uHi3fFddlWJFSCWOHwLlmXlTM3fdcDjshz0JeoNgljgTrDATZVov7y8eiV3IhDZkEsF5It2gtpEHsW/qGFey8IZiWNh8EzCfdQW7yv46+KJSDNdujiWyNeMLuHryxTA7/rJ0ENctO5dfJ8OvdJNzslSZmVx3+YAlRaXM8Hzcdy/m41Rl3ybZ8EjZYLxIscgnM+HF7lBbN42HkLLBc6QZ2ixH9a1ok5tMDH1xfLbBFSo6F8pOQEZhdLqOMnQl5Vg+IPKKeaH33OSomIiuKU9jR0lEnoRlrVgFVixEB+VOy834f8UUdlL6bCwUtLSynYmsqyna2M2k+USqJw7EePL/bA08gC1D9E+m3bpbgI44WUTq25EsQkyonBCU5QfPqRZIti+Pn3Kcb/g7K1zcEabBtczOF3wqx8UoFl34NPuG66i2J0D/VU3+NvX6OdpeJAnjm1s18IR1zWs7oeBfHO57rilHW0JMQRLERSYULopTd5AWCkqdHX5BN e5tuUqZC dW9R6kH6wvkGNk7S6XBs6NroSYQYWoda6Dv1AB1M5mqeUHWFKKRVwanq6aFSYxPoOnR785JOWxbavNy5lKF7EQM+ILVJWrXtCc6u9UpVIalD+FYsA8dMyUNjlvA5stK3kJD7a8UtoQFBaCqQHljAbifQtGU+MdYpZcCQVhJ6r7cn6cZToLmtThtFoaDr0OB8Azz3K9HdYxXZjEOOOdFgfwf2jxVX/QfRQeHWysfq31GcvStebhVL+yNK0fRhBDbiIX3wQszBYMHZ/GJicntI3H7K1dt4IsSfjIytZdqNZ8AubScFeukYTrye27WKhs9h4gsh46RmajT+xxF1vScuOM+gr0aIrgTTyUT3SPjS+zFMo5L4= 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 Thu, Apr 18, 2024 at 10:19:33PM +0200, Jesper Dangaard Brouer wrote: > I'm not sure it is "fine" to, explicitly choosing not to use page pool, > and then (ab)use `struct page` member (pp) that intended for page_pool > for other stuff. (In this case create a linked list of pages). > > +#define page_chain_next(p) ((struct page *)((p)->pp)) > +#define page_chain_add(p, n) ((p)->pp = (void *)n) > > I'm not sure that I (as PP maintainer) can make this call actually, as I > think this area belong with the MM "page" maintainers (Cc MM-list + > people) to judge. > > Just invention new ways to use struct page fields without adding your > use-case to struct page, will make it harder for MM people to maintain > (e.g. make future change). I can't really follow what's being proposed; the quoting is quite deep. Here's the current plan for struct page: - The individual users are being split off. This has already happened for struct folio, struct slab and struct pgdesc. Others are hopefully coming. - At some point, struct page will become: struct page { unsigned long flags; unsigned long data[5]; unsigned int data2[2]; ... some other bits and pieces ... }; - After that, we will turn struct page into: struct page { unsigned long memdesc; }; Users like pagepool will allocate a struct ppdesc that will be referred to by the memdesc. The bottom 4 bits will identify it as a ppdesc. You can put anything you like in a struct ppdesc, it just has to be allocated from a slab with a 16 byte alignment. More details here: https://kernelnewbies.org/MatthewWilcox/Memdescs This is all likely to land in 2025. The goal for 2024 is to remove mapping & index from 'struct page'. This has been in progress since 2019 so I'm really excited that we're so close! If you want to turn struct ppdesc into its own struct like folio, slab & ptdesc, I'm happy to help. I once had a patchset for that: https://lore.kernel.org/netdev/20221130220803.3657490-1-willy@infradead.org/ but I'm sure it's truly bitrotted.