lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Message-ID: <f7919c2c9e1cb6218a0b0f55ddaa9a34f7d2b9a7.camel@gmail.com> Date: Sat, 27 May 2023 08:47:58 -0700 From: Alexander H Duyck <alexander.duyck@...il.com> To: Yunsheng Lin <linyunsheng@...wei.com>, David Howells <dhowells@...hat.com>, netdev@...r.kernel.org Cc: "David S. Miller" <davem@...emloft.net>, Eric Dumazet <edumazet@...gle.com>, Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>, Willem de Bruijn <willemdebruijn.kernel@...il.com>, David Ahern <dsahern@...nel.org>, Matthew Wilcox <willy@...radead.org>, Jens Axboe <axboe@...nel.dk>, linux-mm@...ck.org, linux-kernel@...r.kernel.org, Jeroen de Borst <jeroendb@...gle.com>, Catherine Sullivan <csully@...gle.com>, Shailend Chand <shailend@...gle.com>, Felix Fietkau <nbd@....name>, John Crispin <john@...ozen.org>, Sean Wang <sean.wang@...iatek.com>, Mark Lee <Mark-MC.Lee@...iatek.com>, Lorenzo Bianconi <lorenzo@...nel.org>, Matthias Brugger <matthias.bgg@...il.com>, AngeloGioacchino Del Regno <angelogioacchino.delregno@...labora.com>, Keith Busch <kbusch@...nel.org>, Jens Axboe <axboe@...com>, Christoph Hellwig <hch@....de>, Sagi Grimberg <sagi@...mberg.me>, Chaitanya Kulkarni <kch@...dia.com>, Andrew Morton <akpm@...ux-foundation.org>, linux-arm-kernel@...ts.infradead.org, linux-mediatek@...ts.infradead.org, linux-nvme@...ts.infradead.org Subject: Re: [PATCH net-next 04/12] mm: Make the page_frag_cache allocator use multipage folios On Fri, 2023-05-26 at 19:56 +0800, Yunsheng Lin wrote: > On 2023/5/24 23:33, David Howells wrote: > > Change the page_frag_cache allocator to use multipage folios rather than > > groups of pages. This reduces page_frag_free to just a folio_put() or > > put_page(). > > Hi, David > > put_page() is not used in this patch, perhaps remove it to avoid > the confusion? > Also, Is there any significant difference between __free_pages() > and folio_put()? IOW, what does the 'reduces' part means here? > > I followed some disscusion about folio before, but have not really > understood about real difference between 'multipage folios' and > 'groups of pages' yet. Is folio mostly used to avoid the confusion > about whether a page is 'headpage of compound page', 'base page' or > 'tailpage of compound page'? Or is there any abvious benefit about > folio that I missed? > > > > > diff --git a/include/linux/mm_types.h b/include/linux/mm_types.h > > index 306a3d1a0fa6..d7c52a5979cc 100644 > > --- a/include/linux/mm_types.h > > +++ b/include/linux/mm_types.h > > @@ -420,18 +420,13 @@ static inline void *folio_get_private(struct folio *folio) > > } > > > > struct page_frag_cache { > > - void * va; > > -#if (PAGE_SIZE < PAGE_FRAG_CACHE_MAX_SIZE) > > - __u16 offset; > > - __u16 size; > > -#else > > - __u32 offset; > > -#endif > > + struct folio *folio; > > + unsigned int offset; > > /* we maintain a pagecount bias, so that we dont dirty cache line > > * containing page->_refcount every time we allocate a fragment. > > */ > > - unsigned int pagecnt_bias; > > - bool pfmemalloc; > > + unsigned int pagecnt_bias; > > + bool pfmemalloc; > > }; > > It seems 'va' and 'size' field is used to avoid touching 'stuct page' to > avoid possible cache bouncing when there is more frag can be allocated > from the page while other frags is freed at the same time before this patch? > It might be worth calling that out in the commit log or split it into another > patch to make it clearer and easier to review? Yes, there is a cost for going from page to virtual address. That is why we only use the page when we finally get to freeing or resetting the pagecnt_bias. Also I have some concerns about going from page to folio as it seems like the folio_alloc setups the transparent hugepage destructor instead of using the compound page destructor. I would think that would slow down most users as it looks like there is a spinlock that is taken in the hugepage destructor that isn't there in the compound page destructor.
Powered by blists - more mailing lists