From: Konrad Rzeszutek Wilk <konrad@kernel.org>
To: Alexander Duyck <alexander.h.duyck@intel.com>
Cc: Hillf Danton <dhillf@gmail.com>,
konrad.wilk@oracle.com, tglx@linutronix.de, mingo@redhat.com,
hpa@zytor.com, rob@landley.net, akpm@linux-foundation.org,
joerg.roedel@amd.com, bhelgaas@google.com, shuahkhan@gmail.com,
fujita.tomonori@lab.ntt.co.jp, linux-kernel@vger.kernel.org,
x86@kernel.org
Subject: Re: [PATCH v2 1/7] swiotlb: Make io_tlb_end a physical address instead of a virtual one
Date: Thu, 18 Oct 2012 08:41:44 -0400 [thread overview]
Message-ID: <20121018124143.GA13854@localhost.localdomain> (raw)
In-Reply-To: <507C2F20.8000504@intel.com>
On Mon, Oct 15, 2012 at 08:43:28AM -0700, Alexander Duyck wrote:
> On 10/13/2012 05:52 AM, Hillf Danton wrote:
> > Hi Alexander,
> >
> > On Fri, Oct 12, 2012 at 4:34 AM, Alexander Duyck
> > <alexander.h.duyck@intel.com> wrote:
> >> This change replaces all references to the virtual address for io_tlb_end
> >> with references to the physical address io_tlb_end. The main advantage of
> >> replacing the virtual address with a physical address is that we can avoid
> >> having to do multiple translations from the virtual address to the physical
> >> one needed for testing an existing DMA address.
> >>
> >> Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com>
> >> ---
> >>
> >> lib/swiotlb.c | 24 +++++++++++++-----------
> >> 1 files changed, 13 insertions(+), 11 deletions(-)
> >>
> >> diff --git a/lib/swiotlb.c b/lib/swiotlb.c
> >> index f114bf6..19aac9f 100644
> >> --- a/lib/swiotlb.c
> >> +++ b/lib/swiotlb.c
> >> @@ -57,7 +57,8 @@ int swiotlb_force;
> >> * swiotlb_tbl_sync_single_*, to see if the memory was in fact allocated by this
> >> * API.
> >> */
> >> -static char *io_tlb_start, *io_tlb_end;
> >> +static char *io_tlb_start;
> >> +phys_addr_t io_tlb_end;
> > If add io_tlb_start_phy and io_tlb_end_phy, could we get same results
> > with less hunks?
> >
> > Hillf
>
> What do you mean by less hunks? Are you referring to the memory space?
As in less patch movements.
> If so, then the patches I am submitting do not impact how much space is
> used for the bounce buffer. The only real result of these patches is
> that the total code path is significantly reduced since we don't have to
> perform any virtual to physical translations in the hot-path.
No. He is referring that you can keep io_tlb_end still here. Just
do the computation of the physical address in the init path (of the end).
Then you don't need to do the shifting in the 'is-this-swiotlb-buffer'
and can just do a simple:
if (dma_addr >= io_tlb_start && dma_addr <= io_tlb_end)
next prev parent reply other threads:[~2012-10-18 12:41 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-10-11 20:34 [PATCH v2 0/7] Improve swiotlb performance by using physical addresses Alexander Duyck
2012-10-11 20:34 ` [PATCH v2 1/7] swiotlb: Make io_tlb_end a physical address instead of a virtual one Alexander Duyck
2012-10-13 12:52 ` Hillf Danton
2012-10-15 15:43 ` Alexander Duyck
2012-10-18 12:41 ` Konrad Rzeszutek Wilk [this message]
2012-10-18 15:53 ` Alexander Duyck
2012-10-19 14:18 ` Konrad Rzeszutek Wilk
2012-10-19 16:21 ` Alexander Duyck
2012-10-11 20:34 ` [PATCH v2 2/7] swiotlb: Make io_tlb_start " Alexander Duyck
2012-10-11 20:34 ` [PATCH v2 3/7] swiotlb: Make io_tlb_overflow_buffer a physical address Alexander Duyck
2012-10-11 20:34 ` [PATCH v2 4/7] swiotlb: Return physical addresses when calling swiotlb_tbl_map_single Alexander Duyck
2012-10-11 20:34 ` [PATCH v2 5/7] swiotlb: Use physical addresses for swiotlb_tbl_unmap_single Alexander Duyck
2012-10-11 20:34 ` [PATCH v2 6/7] swiotlb: Use physical addresses instead of virtual in swiotlb_tbl_sync_single Alexander Duyck
2012-10-11 20:34 ` [PATCH v2 7/7] swiotlb: Do not export swiotlb_bounce since there are no external consumers Alexander Duyck
2012-10-12 16:05 ` [PATCH v2 0/7] Improve swiotlb performance by using physical addresses Alexander Duyck
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=20121018124143.GA13854@localhost.localdomain \
--to=konrad@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=alexander.h.duyck@intel.com \
--cc=bhelgaas@google.com \
--cc=dhillf@gmail.com \
--cc=fujita.tomonori@lab.ntt.co.jp \
--cc=hpa@zytor.com \
--cc=joerg.roedel@amd.com \
--cc=konrad.wilk@oracle.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=rob@landley.net \
--cc=shuahkhan@gmail.com \
--cc=tglx@linutronix.de \
--cc=x86@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