From: Joerg Roedel <joerg.roedel@amd.com>
To: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
Cc: linux-kernel@vger.kernel.org, mingo@elte.hu
Subject: Re: [PATCH] x86: avoid unnecessary low zone allocation in AMD IOMMU's alloc_coherent
Date: Wed, 10 Sep 2008 15:53:47 +0200 [thread overview]
Message-ID: <20080910135347.GI6329@amd.com> (raw)
In-Reply-To: <20080910223735O.fujita.tomonori@lab.ntt.co.jp>
On Wed, Sep 10, 2008 at 10:37:45PM +0900, FUJITA Tomonori wrote:
> On Wed, 10 Sep 2008 15:10:32 +0200
> Joerg Roedel <joerg.roedel@amd.com> wrote:
> > Can't we simply make the gfp hacks depend on
> > dma_ops->is_phys and avoid further gfp hacks in the hardware iommu
> > implementations?
>
> I thought about it but adding a new dma_ops->we_don't_want_gfp_flag
> hook doesn't make the code simpler much. Currently, we have the gfp
> setting hack in just one place. It's not bad. Adding such new hook
> means adding more lines than we can remove.
The is_phys flas is already in place and its meaning is "the dma_ops
return bus addresses equal to physical addresses". This is exactly the
case when we need the gfp hacks. So I don't see a problem in just
skipping the gfp rewrite if is_phys is zero. I don't see a point in
adding gfp flags in dma_alloc_coherent and remove them again
dma_ops->alloc_coherent code. Specially in this case where we already
know in dma_alloc_coherent if we really need the flag rewrite.
> Yeah, I was against your patch to adding the gfp setting hack to
> swiotlb but it's because gfp is kinda architecture specific stuff and
> swiotlb should not. It's the bad design IMO. It's ok for me that
> architecture specific IOMMUs can do the architecture specific stuff
> (and it's about just clearing the gfp flag).
The generic swiotlb code already contained a gfp hack for IA64 and I
added another one for x86 which is ok in my opinion. But the #ifdef was
ugly, I agree with that now :-)
Your solution of removing the flag hacks from the generic code completly
was the other possible way.
Joerg
--
| AMD Saxony Limited Liability Company & Co. KG
Operating | Wilschdorfer Landstr. 101, 01109 Dresden, Germany
System | Register Court Dresden: HRA 4896
Research | General Partner authorized to represent:
Center | AMD Saxony LLC (Wilmington, Delaware, US)
| General Manager of AMD Saxony LLC: Dr. Hans-R. Deppe, Thomas McCoy
next prev parent reply other threads:[~2008-09-10 13:54 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-09-10 11:19 [PATCH] x86: avoid unnecessary low zone allocation in AMD IOMMU's alloc_coherent FUJITA Tomonori
2008-09-10 11:57 ` Ingo Molnar
2008-09-10 12:03 ` Joerg Roedel
2008-09-10 12:18 ` Ingo Molnar
2008-09-10 12:38 ` FUJITA Tomonori
2008-09-10 12:48 ` Joerg Roedel
2008-09-10 13:03 ` FUJITA Tomonori
2008-09-10 13:10 ` Joerg Roedel
2008-09-10 13:37 ` FUJITA Tomonori
2008-09-10 13:53 ` Joerg Roedel [this message]
2008-09-10 14:24 ` FUJITA Tomonori
2008-09-10 14:38 ` Joerg Roedel
2008-09-10 14:45 ` FUJITA Tomonori
2008-09-11 9:10 ` Joerg Roedel
2008-09-11 13:36 ` FUJITA Tomonori
2008-09-10 14:39 ` FUJITA Tomonori
2008-09-10 14:52 ` Joerg Roedel
2008-09-10 15:09 ` FUJITA Tomonori
2008-09-10 15:29 ` Joerg Roedel
2008-09-10 16:29 ` FUJITA Tomonori
2008-09-10 17:05 ` Joerg Roedel
2008-09-10 17:15 ` FUJITA Tomonori
2008-09-10 17:25 ` Joerg Roedel
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=20080910135347.GI6329@amd.com \
--to=joerg.roedel@amd.com \
--cc=fujita.tomonori@lab.ntt.co.jp \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.