From: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
To: Keith Busch <kbusch@kernel.org>,
Andrew Morton <akpm@linux-foundation.org>
Cc: Christoph Hellwig <hch@infradead.org>,
Keith Busch <kbusch@meta.com>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] dmapool: push new blocks in ascending order
Date: Fri, 24 Feb 2023 22:28:30 +0000 [thread overview]
Message-ID: <d768c2b8-1649-6565-0367-a0e07cc01b03@linaro.org> (raw)
In-Reply-To: <Y/kA1Tp5wIZSiY4q@kbusch-mbp.dhcp.thefacebook.com>
On 24/02/2023 18:24, Keith Busch wrote:
> On Thu, Feb 23, 2023 at 12:41:37PM -0800, Andrew Morton wrote:
>> On Tue, 21 Feb 2023 11:07:32 -0700 Keith Busch <kbusch@kernel.org> wrote:
>>
>>> On Tue, Feb 21, 2023 at 10:02:34AM -0800, Christoph Hellwig wrote:
>>>> On Tue, Feb 21, 2023 at 08:54:00AM -0800, Keith Busch wrote:
>>>>> From: Keith Busch <kbusch@kernel.org>
>>>>>
>>>>> Some users of the dmapool need their allocations to happen in ascending
>>>>> order. The recent optimizations pushed the blocks in reverse order, so
>>>>> restore the previous behavior by linking the next available block from
>>>>> low-to-high.
>>>>
>>>> Who are those users?
>>>>
>>>> Also should we document this behavior somewhere so that it isn't
>>>> accidentally changed again some time in the future?
>>>
>>> usb/chipidea/udc.c qh_pool called "ci_hw_qh".
>>
>> It would be helpful to know why these users need this side-effect. Did
>> the drivers break? Or just get slower?
>
> The affected driver was reported to be unusable without this behavior.
>
>> Are those drivers misbehaving by assuming this behavior? Should we
>
> I do think they're using the wrong API. You you shouldn't use the dmapool if
> your blocks need to be arranged in a contiguous address order. They should just
> directly use dma_alloc_coherent() instead.
>
>> require that they be altered instead of forever constraining the dmapool
>> implementation in this fashion?
>
> This change isn't really constraining dmapool where it matters. It's just an
> unexpected one-time initialization thing.
>
> As far as altering those drivers, I'll reach out to someone on that side for
> comment (I'm currently not familiar with the affected subsystem).
We can always change this driver, I'm fine to do that in-parallel/instead.
The symptom we have is a silent failure absent this change so, I just
wonder are we really the _only_ code path that would be affected absent
the change in this patch ?
---
bod
next prev parent reply other threads:[~2023-02-24 22:28 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-02-21 16:54 Keith Busch
2023-02-21 17:20 ` Bryan O'Donoghue
2023-02-21 18:02 ` Christoph Hellwig
2023-02-21 18:07 ` Keith Busch
2023-02-23 20:41 ` Andrew Morton
2023-02-24 18:24 ` Keith Busch
2023-02-24 22:28 ` Bryan O'Donoghue [this message]
2023-02-26 4:42 ` Andrew Morton
2023-02-27 17:20 ` Keith Busch
2023-02-28 1:25 ` Keith Busch
2023-02-28 2:14 ` Guenter Roeck
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=d768c2b8-1649-6565-0367-a0e07cc01b03@linaro.org \
--to=bryan.odonoghue@linaro.org \
--cc=akpm@linux-foundation.org \
--cc=hch@infradead.org \
--cc=kbusch@kernel.org \
--cc=kbusch@meta.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.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