[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20220120171723.GT84788@nvidia.com>
Date: Thu, 20 Jan 2022 13:17:23 -0400
From: Jason Gunthorpe <jgg@...dia.com>
To: Christoph Hellwig <hch@....de>
Cc: Matthew Wilcox <willy@...radead.org>, linux-kernel@...r.kernel.org,
Joao Martins <joao.m.martins@...cle.com>,
John Hubbard <jhubbard@...dia.com>,
Logan Gunthorpe <logang@...tatee.com>,
Ming Lei <ming.lei@...hat.com>, linux-block@...r.kernel.org,
netdev@...r.kernel.org, linux-mm@...ck.org,
linux-rdma@...r.kernel.org, dri-devel@...ts.freedesktop.org,
nvdimm@...ts.linux.dev
Subject: Re: Phyr Starter
On Thu, Jan 20, 2022 at 03:03:40PM +0100, Christoph Hellwig wrote:
> On Wed, Jan 12, 2022 at 06:37:03PM +0000, Matthew Wilcox wrote:
> > But let's go further than that (which only brings us to 32 bytes per
> > range). For the systems you care about which use an identity mapping,
> > and have sizeof(dma_addr_t) == sizeof(phys_addr_t), we can simply
> > point the dma_range pointer to the same memory as the phyr. We just
> > have to not free it too early. That gets us down to 16 bytes per range,
> > a saving of 33%.
>
> Even without an IOMMU the dma_addr_t can have offsets vs the actual
> physical address. Not on x86 except for a weirdo SOC, but just about
> everywhere else.
The point is dma_map knows if that is happening or not and giving
dma_map the option to just return a pointer to the input memory to
re-use as the dma list does optimize important widely used cases.
Yes, some weirdo SOC cannot do this optimization, but the weirdo SOC
will allocate a new memory and return the adjusted dma_addr_t just
fine.
Ideally we should not pay a cost for weirdo SOC on sane systems.
Jason
Powered by blists - more mailing lists