From: Benjamin Herrenschmidt <benh@au1.ibm.com>
To: Christoph Hellwig <hch@lst.de>
Cc: iommu@lists.linux-foundation.org,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Russell Currey <ruscur@au1.ibm.com>,
Jens Axboe <jens.axboe@oracle.com>
Subject: DMA mappings and crossing boundaries
Date: Sun, 24 Jun 2018 17:32:50 +1000 [thread overview]
Message-ID: <2d752386b82481bc53080fcee1a3dcd474dbeef2.camel@au1.ibm.com> (raw)
Hi Folks !
So due work around issues with devices having to strict limitations in
DMA address bits (GPUs ugh....) on POWER, we've been playing with a
mechanism that does dynamic mapping in the IOMMU but using a very large
IOMMU page size (256M on POWER8 and 1G on POWER9) for performances.
Now, with such page size, we can't just pop out new entries for every
DMA map, we need to try to re-use entries for mappings in the same
"area".
We've prototypes something using refcounts on the entires. It does
imply some locking which is potentially problematic, and we'll be
looking at options there long run, but it works... so far.
My worry is that it will fail if we ever get a mapping request (or
coherent allocation request) that spawns one of those giant pages
boundaries. At least our current implementation.
AFAIK, dma_alloc_coherent() is defined (Documentation/DMA-API-
HOWTO.txt) as always allocating to the next power-of-2 order, so we
should never have the problem unless we allocate a single chunk larger
than the IOMMU page size.
For dma_map_sg() however, if a request that has a single "entry"
spawning such a boundary, we need to ensure that the result mapping is
2 contiguous "large" iommu pages as well.
However, that doesn't fit well with us re-using existing mappings since
they may already exist and either not be contiguous, or partially exist
with no free hole around them.
Now, we *could* possibly construe a way to solve this by detecting this
case and just allocating another "pair" (or set if we cross even more
pages) of IOMMU pages elsewhere, thus partially breaking our re-use
scheme.
But while doable, this introduce some serious complexity in the
implementation, which I would very much like to avoid.
So I was wondering if you guys thought that was ever likely to happen ?
Do you see reasonable cases where dma_map_sg() would be called with a
list in which a single entry crosses a 256M or 1G boundary ?
Cheers,
Ben.
next reply other threads:[~2018-06-24 7:33 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-06-24 7:32 Benjamin Herrenschmidt [this message]
2018-07-02 13:06 ` Robin Murphy
2018-07-02 13:37 ` Benjamin Herrenschmidt
2018-07-04 12:57 ` Robin Murphy
2018-07-11 4:51 ` Benjamin Herrenschmidt
2018-07-20 3:12 ` Benjamin Herrenschmidt
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2d752386b82481bc53080fcee1a3dcd474dbeef2.camel@au1.ibm.com \
--to=benh@au1.ibm.com \
--cc=hch@lst.de \
--cc=iommu@lists.linux-foundation.org \
--cc=jens.axboe@oracle.com \
--cc=linux-kernel@vger.kernel.org \
--cc=ruscur@au1.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®