-B21284; linuxppc-dev@lists.ozlabs.org; Xie
> Shaohui-B21989; Chen Yuanquan-B41889
> Subject: Re: [PATCH] powerpc/mm: add ZONE_NORMAL zone for 64 bit kernel
>
> On Tue, 2012-07-24 at 04:04 +, Tabi Timur-B04825 wrote:
> > Benjamin Herrenschmidt wrote:
> > > Sure but I don&#x
On Tue, 2012-07-24 at 04:04 +, Tabi Timur-B04825 wrote:
> Benjamin Herrenschmidt wrote:
> > Sure but I don't want to create the zones in the first place (and thus
> > introduce the added pressure on the memory management) on machines that
> > don't need it.
>
> One thing that does confuse me -
Benjamin Herrenschmidt wrote:
> Sure but I don't want to create the zones in the first place (and thus
> introduce the added pressure on the memory management) on machines that
> don't need it.
One thing that does confuse me -- by default, we don't create a
ZONE_NORMAL. We only create a ZONE_DMA
-B21284; linuxppc-dev@lists.ozlabs.org;
> Xie Shaohui-B21989; Chen Yuanquan-B41889
> Subject: Re: [PATCH] powerpc/mm: add ZONE_NORMAL zone for 64 bit kernel
>
> On Mon, 2012-07-23 at 18:36 -0500, Timur Tabi wrote:
> > The DMA zone only kicks in if the DMA mask is set to a size smaller
> &
Benjamin Herrenschmidt wrote:
> Sure but I don't want to create the zones in the first place (and thus
> introduce the added pressure on the memory management) on machines that
> don't need it.
Ah yes, I forgot about memory pressure.
--
Timur Tabi
Linux kernel developer at Freescale
On Mon, 2012-07-23 at 18:36 -0500, Timur Tabi wrote:
> The DMA zone only kicks in if the DMA mask is set to a size smaller
> that
> available physical memory. Sane HW should set the DMA mask to
> DMA_BIT_MASK(36). And we have plenty of sane HW on our SOCs, but not
> every device is like that.
>
On 07/23/2012 05:20 PM, Benjamin Herrenschmidt wrote:
> On Mon, 2012-07-23 at 11:17 -0500, Scott Wood wrote:
>>> This is wrong.
>>
>> How so?
>>
>>> Don't you have an iommu do deal with those devices anyway ?
>>
>> Yes, but we don't yet have DMA API support for it, it would lower
>> performance bec
On 07/23/2012 06:30 PM, Benjamin Herrenschmidt wrote:
> On Tue, 2012-07-24 at 09:29 +1000, Benjamin Herrenschmidt wrote:
>
>> The layers in between, not the well behaved drivers. Again, we have
>> ZONE_DMA32 specifically for the purpose, why use something else ?
>>
>> In any case, make the whole t
Benjamin Herrenschmidt wrote:
> No, but dma_alloc_coherent would under the hood.
Which is what Shaohui's patch does. Well, it does it for GFP_DMA instead
of GFP_DMA32, but still.
When you said, "Drivers who know about a 32-bit limitations use
GFP_DMA32", I thought you meant that drivers should
On Tue, 2012-07-24 at 09:29 +1000, Benjamin Herrenschmidt wrote:
> The layers in between, not the well behaved drivers. Again, we have
> ZONE_DMA32 specifically for the purpose, why use something else ?
>
> In any case, make the whole thing at the very least a config option, I
> don't want sane H
On Mon, 2012-07-23 at 18:15 -0500, Timur Tabi wrote:
> Benjamin Herrenschmidt wrote:
> > Sure, that's the right way to go, I meant bits of pieces of the
> > infrastructure in between. Why diverge from other archs gratuituously
> > here ?
>
> Ok, I'm confused. Are you suggesting that drivers do th
Benjamin Herrenschmidt wrote:
> Sure, that's the right way to go, I meant bits of pieces of the
> infrastructure in between. Why diverge from other archs gratuituously
> here ?
Ok, I'm confused. Are you suggesting that drivers do this:
u64 fsl_dma_dmamask = DMA_BIT_MASK(36);
dev->dma_mask = &fsl
On Mon, 2012-07-23 at 23:08 +, Tabi Timur-B04825 wrote:
>
> > And ? Who cares ? Drivers who know about a 32-bit limitations use
> > GFP_DMA32, that's what is expected, don't mess around with ZONE_DMA.
>
> I thought drivers are supposed to set a dma_mask, and
> dma_alloc_coherent() is supposed
On Mon, Jul 23, 2012 at 5:20 PM, Benjamin Herrenschmidt
wrote:
> And ? Who cares ? Drivers who know about a 32-bit limitations use
> GFP_DMA32, that's what is expected, don't mess around with ZONE_DMA.
I thought drivers are supposed to set a dma_mask, and
dma_alloc_coherent() is supposed to use
On Mon, 2012-07-23 at 11:17 -0500, Scott Wood wrote:
> > This is wrong.
>
> How so?
>
> > Don't you have an iommu do deal with those devices anyway ?
>
> Yes, but we don't yet have DMA API support for it, it would lower
> performance because we'd have to use a lot of subwindows which are
> poorl
On 07/23/2012 01:06 AM, Benjamin Herrenschmidt wrote:
> On Fri, 2012-07-20 at 20:21 +0800, Shaohui Xie wrote:
>> PowerPC platform only supports ZONE_DMA zone for 64bit kernel, so all the
>> memory will be put into this zone. If the memory size is greater than
>> the device's DMA capability and devi
On Fri, 2012-07-20 at 20:21 +0800, Shaohui Xie wrote:
> PowerPC platform only supports ZONE_DMA zone for 64bit kernel, so all the
> memory will be put into this zone. If the memory size is greater than
> the device's DMA capability and device uses dma_alloc_coherent to allocate
> memory, it will ge
PowerPC platform only supports ZONE_DMA zone for 64bit kernel, so all the
memory will be put into this zone. If the memory size is greater than
the device's DMA capability and device uses dma_alloc_coherent to allocate
memory, it will get an address which is over the device's DMA addressing,
the de
18 matches
Mail list logo
