From: Christoph Hellwig <hch@infradead.org>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Robin Murphy <robin.murphy@arm.com>,
Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
Christoph Hellwig <hch@infradead.org>,
Marek Szyprowski <m.szyprowski@samsung.com>,
Claire Chang <tientzu@chromium.org>,
Stefano Stabellini <sstabellini@kernel.org>,
Will Deacon <will@kernel.org>,
pasic@linux.ibm.com,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [GIT PULL] (swiotlb) stable/for-linus-5.15
Date: Fri, 3 Sep 2021 06:09:44 +0100 [thread overview]
Message-ID: <YTGuGGxAoWMB9/Mg@infradead.org> (raw)
In-Reply-To: <CAHk-=wg35pAyCFC6_hhBTAGGUPprf=hwx5+Ey1tnqXzuaOLsRQ@mail.gmail.com>
On Thu, Sep 02, 2021 at 05:42:11PM -0700, Linus Torvalds wrote:
> On Thu, Sep 2, 2021 at 2:55 PM Robin Murphy <robin.murphy@arm.com> wrote:
> >
> > Not to defend the state things have got into - frankly I've found it
> > increasingly hard to follow for some time now too - but I believe the
> > unwritten story is of the one true dma-direct trying to be all things to
> > all users, and there are several aspects at play here which are mutually
> > exclusive in practice.
>
> Ugh.
>
> Some of that "mutual exclusion" seems to be encoded in peoples heads,
> not in the code itself.
Some of it is. This is mostly because we're still most in stage 1
of the grand plan:
"consolidate 100% identical concepts various architectures reimplement"
which will slowly give way to actually clean up various mostly the same
concepts. And the big items here is the various pools. This simple
coherent pool and the one we use for GFP_ATOMIC alloctions for
not coherent devices would be a very obvious first step. Swiotlb would
be the next one, but it is much more complicated as swiotlb is messy
and has a rather "special" allocator algorithm.
>
> > The global pool is essentially for noMMU, so should not be expected to
> > overlap with SWIOTLB at all, much less systems using restricted DMA.
>
> If I read that right, you're saying that in this case, the possible
> mis-merge doesn't matter?
Currently (and for the foreseeable future) it does not matter.
> Except the dispatch logic ends up being all those different cases that
> have nothing to do with each other, because people have very clearly
> tried to avoid code duplication by just saying "ok, in these two
> entirely unrelated situations, we do the same thing".
Not just that. There are plenty of cases where architectures need
multiple of these cases depending on runtime checks.
But yes, this funtion turned into a mess, and we can improve both
the overall structure and the omments explaining it a fair bit.
next prev parent reply other threads:[~2021-09-03 5:13 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-09-01 21:08 [GIT PULL] (swiotlb) stable/for-linus-5.15 Konrad Rzeszutek Wilk
2021-09-02 18:54 ` Linus Torvalds
2021-09-02 21:55 ` Robin Murphy
2021-09-03 0:42 ` Linus Torvalds
2021-09-03 5:09 ` Christoph Hellwig [this message]
2021-09-03 13:51 ` Robin Murphy
2021-09-03 17:37 ` Linus Torvalds
2021-09-03 18:45 ` pr-tracker-bot
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=YTGuGGxAoWMB9/Mg@infradead.org \
--to=hch@infradead.org \
--cc=konrad.wilk@oracle.com \
--cc=linux-kernel@vger.kernel.org \
--cc=m.szyprowski@samsung.com \
--cc=pasic@linux.ibm.com \
--cc=robin.murphy@arm.com \
--cc=sstabellini@kernel.org \
--cc=tientzu@chromium.org \
--cc=torvalds@linux-foundation.org \
--cc=will@kernel.org \
/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