From: Ilias Apalodimas <email@example.com>
To: Yunsheng Lin <firstname.lastname@example.org>,
Lorenzo Bianconi <email@example.com>
Cc: "David S. Miller" <firstname.lastname@example.org>,
Jakub Kicinski <email@example.com>,
Jesper Dangaard Brouer <firstname.lastname@example.org>,
open list <email@example.com>,
Heiner Kallweit <firstname.lastname@example.org>
Subject: Re: [PATCH net-next v2 2/2] page_pool: optimize the cpu sync operation when DMA mapping
Date: Tue, 24 Aug 2021 12:04:38 +0300 [thread overview]
Message-ID: <CAC_iWj+KiPWjztQsQ-1Qi1rLDCojnzFsK18KYfyLLhsxz0k5FA@mail.gmail.com> (raw)
+cc Lorenzo, which has done some tests on non-coherent platforms
On Tue, 24 Aug 2021 at 10:00, Yunsheng Lin <email@example.com> wrote:
> On 2021/8/23 20:42, Ilias Apalodimas wrote:
> > On Mon, Aug 23, 2021 at 11:56:48AM +0800, Yunsheng Lin wrote:
> >> On 2021/8/20 17:39, Ilias Apalodimas wrote:
> >>> On Fri, Aug 20, 2021 at 02:56:51PM +0800, Yunsheng Lin wrote:
> >> https://elixir.bootlin.com/linux/latest/source/kernel/dma/direct.h#L104
> >> The one thing I am not sure about is that the pool->p.offset
> >> and pool->p.max_len are used to decide the sync range before this
> >> patch, while the sync range is the same as the map range when doing
> >> the sync in dma_map_page_attrs().
> > I am not sure I am following here. We always sync the entire range as well
> > in the current code as the mapping function is called with max_len.
> >> I assumed the above is not a issue? only sync more than we need?
> >> and it won't hurt the performance?
> > We can sync more than we need, but if it's a non-coherent architecture,
> > there's a performance penalty.
> Since I do not have any performance data to prove if there is a
> performance penalty for non-coherent architecture, I will drop it:)
I am pretty sure it does affect it. Unless I am missing something the
patch simply re-arranges calls to avoid calling dma_map_page_attrs()
However since dma_map_page_attrs() won't do anything sync-related
since it's called with DMA_ATTR_SKIP_CPU_SYNC, I doubt calling it will
have any measurable difference. If there is, we should pick it up.
> > Regards
> > /Ilias
prev parent reply other threads:[~2021-08-24 9:05 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-08-20 6:56 [PATCH net-next v2 0/2] Some minor optimization for page pool Yunsheng Lin
2021-08-20 6:56 ` [PATCH net-next v2 1/2] page_pool: use relaxed atomic for release side accounting Yunsheng Lin
2021-08-20 7:12 ` Jesper Dangaard Brouer
2021-08-20 6:56 ` [PATCH net-next v2 2/2] page_pool: optimize the cpu sync operation when DMA mapping Yunsheng Lin
2021-08-20 9:39 ` Ilias Apalodimas
2021-08-23 3:56 ` Yunsheng Lin
2021-08-23 12:42 ` Ilias Apalodimas
2021-08-24 7:00 ` Yunsheng Lin
2021-08-24 9:04 ` Ilias Apalodimas [this message]
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:
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* 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;
as well as URLs for NNTP newsgroup(s).