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: <64f7af75-e6df-7abc-c4ce-82e6ca51fafe@gmail.com> Date: Mon, 11 Feb 2019 09:14:15 -0800 From: Eric Dumazet <eric.dumazet@...il.com> To: Tariq Toukan <tariqt@...lanox.com>, Ilias Apalodimas <ilias.apalodimas@...aro.org>, Matthew Wilcox <willy@...radead.org> Cc: David Miller <davem@...emloft.net>, "brouer@...hat.com" <brouer@...hat.com>, "toke@...hat.com" <toke@...hat.com>, "netdev@...r.kernel.org" <netdev@...r.kernel.org>, "mgorman@...hsingularity.net" <mgorman@...hsingularity.net>, "linux-mm@...ck.org" <linux-mm@...ck.org> Subject: Re: [RFC, PATCH] net: page_pool: Don't use page->private to store dma_addr_t On 02/11/2019 12:53 AM, Tariq Toukan wrote: > > Hi, > > It's great to use the struct page to store its dma mapping, but I am > worried about extensibility. > page_pool is evolving, and it would need several more per-page fields. > One of them would be pageref_bias, a planned optimization to reduce the > number of the costly atomic pageref operations (and replace existing > code in several drivers). > But the point about pageref_bias is to place it in a different cache line than "struct page" The major cost is having a cache line bouncing between producer and consumer. pageref_bias means the producer only have to read the "struct page" and not dirty it in the case the page can be recycled. > I would replace this dma field with a pointer to an extensible struct, > that would contain the dma mapping (and other stuff in the near future). > This pointer fits perfectly with the existing unsigned long private; > they can share the memory, for both 32- and 64-bits systems. > > The only downside is one more pointer de-reference. This should be perf > tested. > However, when introducing the page refcnt bias optimization into > page_pool, I believe the perf gain would be guaranteed. Only in some cases perhaps (when the cache line can be dirtied without performance hit)
Powered by blists - more mailing lists