On Wed, 15 Aug 2007, Andi Kleen wrote:
> BTW I suspect this is true for some other GFP_DMA usages too.
> Some driver writers seem to confuse it with the PCI DMA
> APIs or believe it is always needed for them.
See especially ARM.
-
To unsubscribe from this list: send the line "unsubscribe linux-k
On Wed, Aug 15, 2007 at 02:59:20PM +0200, Andi Kleen wrote:
> On Wed, Aug 15, 2007 at 12:37:49PM +0100, Ralf Baechle wrote:
> > On Tue, Aug 14, 2007 at 02:14:41AM +0200, Andi Kleen wrote:
> >
> > > meth is only used on SGI O2s which are not that slow and unlikely
> > > to work in tree anyways.
>
On Wed, Aug 15, 2007 at 12:37:49PM +0100, Ralf Baechle wrote:
> On Tue, Aug 14, 2007 at 02:14:41AM +0200, Andi Kleen wrote:
>
> > meth is only used on SGI O2s which are not that slow and unlikely
> > to work in tree anyways.
>
> O2 doesn't enable CONFIG_ZONE_DMA so there is no point in using GFP_
On Tue, Aug 14, 2007 at 02:14:41AM +0200, Andi Kleen wrote:
> meth is only used on SGI O2s which are not that slow and unlikely
> to work in tree anyways.
O2 doesn't enable CONFIG_ZONE_DMA so there is no point in using GFP_DMA in
an O2-specific device driver. Will send out patch in separate mail
> Yeah, if you stick a PCI chip with a 30-bit PCI DMA mask into a machine
> with memory above 1GB, then copying has to happen. Unless the memory
> allocator can avoid returning memory in the un-dma-able region...
With GFP_DMA this was possible, but the capability will be gone
for x86 systems if y
On Tue, 14 Aug 2007, Andi Kleen wrote:
> > pci_set_consistent_dma_mask
> >
> > has that.
>
> While on x86 it is roughly identical (although the low level
> allocator is currently not very reliable) it makes a significant
> difference on some platforms. e.g. I was told on PA-RISC
> consistent mem
On Tue, Aug 14, 2007 at 10:23:51PM +0200, Andi Kleen wrote:
> > bcm43xx hardware does show up on low-end MIPS boxes (wrt54g anybody?)
> > that would be sorely hurt by excess copies.
>
> Lowend boxes don't have more than 1GB of RAM. With <= 1GB you don't
> need to copy on bcm43xx.
OK, that makes s
> bcm43xx hardware does show up on low-end MIPS boxes (wrt54g anybody?)
> that would be sorely hurt by excess copies.
Lowend boxes don't have more than 1GB of RAM. With <= 1GB you don't
need to copy on bcm43xx.
-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the
On Tue, Aug 14, 2007 at 02:14:41AM +0200, Andi Kleen wrote:
> On Tue, Aug 14, 2007 at 12:22:23AM +0100, Alan Cox wrote:
> > > The only tricky part were skbs in a few drivers, but luckily they are only
> > > needed for bouncing which can be done without a skb too. For RX it adds
> > > one copy, but
> So the only systems really affected are lance systems with >16MB.
> I don't think we can stop Linux evolution for those sorry. They'll
> just have to live with it.
I think thats fair enough too.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
On Mon, Aug 13, 2007 at 04:25:23PM -0700, Christoph Lameter wrote:
> On Tue, 14 Aug 2007, Andi Kleen wrote:
>
> > > But they use GFP_DMA right now and drivers cannot use DMA32 if they want
> >
> > The way it was originally designed was that they use GFP_DMA32,
> > which would map to itself on x8
On Mon, Aug 13, 2007 at 04:27:42PM -0700, Christoph Lameter wrote:
> On Tue, 14 Aug 2007, Andi Kleen wrote:
>
> > > Ok then lets do it.
> >
> > Conversion only makes sense once an API with a explicit mask
> > is in. Otherwise we have muddled semantics again.
>
> pci_set_consistent_dma_mask
>
>
On Tue, 14 Aug 2007, Andi Kleen wrote:
> > Ok then lets do it.
>
> Conversion only makes sense once an API with a explicit mask
> is in. Otherwise we have muddled semantics again.
pci_set_consistent_dma_mask
has that.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> Ok then lets do it.
Conversion only makes sense once an API with a explicit mask
is in. Otherwise we have muddled semantics again.
-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.ke
On Tue, 14 Aug 2007, Andi Kleen wrote:
> > But they use GFP_DMA right now and drivers cannot use DMA32 if they want
>
> The way it was originally designed was that they use GFP_DMA32,
> which would map to itself on x86-64, to GFP_DMA on ia64 and to
> GFP_KERNEL on i386. Unfortunately that seems
On Tue, Aug 14, 2007 at 12:22:23AM +0100, Alan Cox wrote:
> > The only tricky part were skbs in a few drivers, but luckily they are only
> > needed for bouncing which can be done without a skb too. For RX it adds
> > one copy, but we can live with that because they're only slow devices.
>
> Usuall
On Mon, Aug 13, 2007 at 04:12:17PM -0700, Christoph Lameter wrote:
> On Tue, 14 Aug 2007, Andi Kleen wrote:
>
> > > What would be the point?
> >
> > "so that drivers not need to ifdef"
>
> But they use GFP_DMA right now and drivers cannot use DMA32 if they want
The way it was originally desig
On Tue, 14 Aug 2007, Andi Kleen wrote:
> > > I converted all of those that applied to x86.
> >
> > Converted to what?
>
> Hmm, do you actually read my emails? I spelled that out at least two
> times now. It's converted to a new dma page allocator that specifies
> an address mask.
Yes I do but f
> The only tricky part were skbs in a few drivers, but luckily they are only
> needed for bouncing which can be done without a skb too. For RX it adds
> one copy, but we can live with that because they're only slow devices.
Usually found on slow hardware that can't cope with extra copies very
well
On Tue, 14 Aug 2007, Andi Kleen wrote:
> > What would be the point?
>
> "so that drivers not need to ifdef"
But they use GFP_DMA right now and drivers cannot use DMA32 if they want
to be cross platforms compatible? Doesnt the dma API completely do away
with these things?
-
To unsubscribe fro
On Mon, Aug 13, 2007 at 03:54:34PM -0700, Christoph Lameter wrote:
> On Tue, 14 Aug 2007, Andi Kleen wrote:
>
> > On Mon, Aug 13, 2007 at 03:38:10PM -0700, Christoph Lameter wrote:
> > > I just did a grep for GFP_DMA and I still see a large list of GFP_DMA
> > > kmallocs???
> >
> > I converted a
On Mon, Aug 13, 2007 at 03:52:54PM -0700, Christoph Lameter wrote:
> On Tue, 14 Aug 2007, Andi Kleen wrote:
>
> > > I am not sure what you mean by that. Ia64 ZONE_DMA == x86_84 ZONE_DMA32?
> >
> > Hmm, when I wrote GFP_DMA32 it was a #define GFP_DMA32 GFP_DMA
> > on ia64 so that drivers not need
On Tue, 14 Aug 2007, Andi Kleen wrote:
> On Mon, Aug 13, 2007 at 03:38:10PM -0700, Christoph Lameter wrote:
> > I just did a grep for GFP_DMA and I still see a large list of GFP_DMA
> > kmallocs???
>
> I converted all of those that applied to x86.
Converted to what?
drivers/scsi/sr_ioctl.c:
On Tue, 14 Aug 2007, Andi Kleen wrote:
> > I am not sure what you mean by that. Ia64 ZONE_DMA == x86_84 ZONE_DMA32?
>
> Hmm, when I wrote GFP_DMA32 it was a #define GFP_DMA32 GFP_DMA
> on ia64 so that drivers not need to ifdef. Someone nasty
> seems to have removed that too. I guess it would be
On Mon, Aug 13, 2007 at 03:38:10PM -0700, Christoph Lameter wrote:
> I just did a grep for GFP_DMA and I still see a large list of GFP_DMA
> kmallocs???
I converted all of those that applied to x86.
-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a
On Mon, Aug 13, 2007 at 03:22:25PM -0700, Christoph Lameter wrote:
> On Tue, 14 Aug 2007, Andi Kleen wrote:
>
> > > x86_64 is the only platforms that uses ZONE_DMA32. Ia64 and other 64 bit
> > > platforms use ZONE_DMA for <4GB allocs.
> >
> > Yes, but ZONE_DMA32 == ZONE_DMA.
>
> I am not sure w
I just did a grep for GFP_DMA and I still see a large list of GFP_DMA
kmallocs???
arch/mips/au1000/common/dbdma.c:if ((desc_base =
(u32)kmalloc(i, GFP_KERNEL|GFP_DMA)) == 0)
arch/m68k/kernel/dma.c: map = kmalloc(sizeof(struct page *) << order, flag &
~__GFP_DMA);
arch/s390/hypf
On Tue, 14 Aug 2007, Andi Kleen wrote:
> > x86_64 is the only platforms that uses ZONE_DMA32. Ia64 and other 64 bit
> > platforms use ZONE_DMA for <4GB allocs.
>
> Yes, but ZONE_DMA32 == ZONE_DMA.
I am not sure what you mean by that. Ia64 ZONE_DMA == x86_84 ZONE_DMA32?
> Also when the slab use
On Mon, Aug 13, 2007 at 03:09:55PM -0700, Christoph Lameter wrote:
> > > > There are still other architectures that use it. Biggest offender
> > > > is s390. I'll leave them to their respective maintainers.
> > >
> > > IA64 also uses ZONE_DMA to support 32bit controllers.
> >
> > ZONE_DMA32 I th
On Tue, 14 Aug 2007, Andi Kleen wrote:
> On Mon, Aug 13, 2007 at 03:00:14PM -0700, Christoph Lameter wrote:
> > You said that ZONE_DMA will still be there right? So the zone will be
>
> There will be a (variable sized) dma zone, but not a ZONE_DMA entry in pgdat
> or in the the fallback lists.
On Mon, Aug 13, 2007 at 03:00:14PM -0700, Christoph Lameter wrote:
> You said that ZONE_DMA will still be there right? So the zone will be
There will be a (variable sized) dma zone, but not a ZONE_DMA entry in pgdat
or in the the fallback lists.
>
> > There are still other architectures that u
On Mon, Aug 13, 2007 at 02:25:36PM -0700, Christoph Lameter wrote:
> On Sat, 11 Aug 2007, Andi Kleen wrote:
>
> > > Hallelujah. You are my hero! x86_64 will switch off CONFIG_ZONE_DMA?
> >
> > Yes. i386 too actually.
> >
> > The DMA zone will be still there, but only reachable with special funct
On Tue, 14 Aug 2007, Andi Kleen wrote:
> > > The DMA zone will be still there, but only reachable with special
> > > functions.
> >
> > Not too happy with that one but this is going the right direcrtion.
> >
> > On NUMA this would still mean allocating space for the DMA zone on all
> > nodes a
On Sat, 11 Aug 2007, Andi Kleen wrote:
> > Hallelujah. You are my hero! x86_64 will switch off CONFIG_ZONE_DMA?
>
> Yes. i386 too actually.
>
> The DMA zone will be still there, but only reachable with special functions.
Not too happy with that one but this is going the right direcrtion.
On NU
On Friday 10 August 2007 21:02, Christoph Lameter wrote:
> On Fri, 10 Aug 2007, Andi Kleen wrote:
> > > x86_64 does not support ZONE_HIGHMEM.
> >
> > I also plan to eliminate ZONE_DMA soon (and replace all its users
> > with a new allocator that sits outside the normal fallback lists)
>
> Halleluja
On Fri, 10 Aug 2007, Andi Kleen wrote:
>
> > x86_64 does not support ZONE_HIGHMEM.
>
> I also plan to eliminate ZONE_DMA soon (and replace all its users
> with a new allocator that sits outside the normal fallback lists)
Hallelujah. You are my hero! x86_64 will switch off CONFIG_ZONE_DMA?
-
> x86_64 does not support ZONE_HIGHMEM.
I also plan to eliminate ZONE_DMA soon (and replace all its users
with a new allocator that sits outside the normal fallback lists)
-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTE
On Fri, 10 Aug 2007, Mel Gorman wrote:
> On (09/08/07 18:44), Christoph Lameter didst pronounce:
> >
> > On Fri, 10 Aug 2007, Mel Gorman wrote:
> >
> > > > > +#if defined(CONFIG_SMP) && INTERNODE_CACHE_SHIFT > ZONES_SHIFT
> > > >
> > > > Is this necessary? ZONES_SHIFT is always <= 2 so it will
On (09/08/07 18:44), Christoph Lameter didst pronounce:
>
> On Fri, 10 Aug 2007, Mel Gorman wrote:
>
> > > > +#if defined(CONFIG_SMP) && INTERNODE_CACHE_SHIFT > ZONES_SHIFT
> > >
> > > Is this necessary? ZONES_SHIFT is always <= 2 so it will work with
> > > any pointer. Why disable this for UP?
On Fri, 10 Aug 2007, Mel Gorman wrote:
> > > +#if defined(CONFIG_SMP) && INTERNODE_CACHE_SHIFT > ZONES_SHIFT
> >
> > Is this necessary? ZONES_SHIFT is always <= 2 so it will work with
> > any pointer. Why disable this for UP?
> >
>
> Caution in case the number of zones increases. There was no
On (09/08/07 14:37), Christoph Lameter didst pronounce:
> On Thu, 9 Aug 2007, Mel Gorman wrote:
>
> > }
> >
> > +#if defined(CONFIG_SMP) && INTERNODE_CACHE_SHIFT > ZONES_SHIFT
>
> Is this necessary? ZONES_SHIFT is always <= 2 so it will work with
> any pointer. Why disable this for UP?
>
Ca
On Thu, 9 Aug 2007, Mel Gorman wrote:
> }
>
> +#if defined(CONFIG_SMP) && INTERNODE_CACHE_SHIFT > ZONES_SHIFT
Is this necessary? ZONES_SHIFT is always <= 2 so it will work with
any pointer. Why disable this for UP?
> --- linux-2.6.23-rc1-mm2-010_use_zonelist/mm/vmstat.c 2007-08-07
> 14:45:1
Using one zonelist per node requires very frequent use of zone_idx(). This
is costly as it involves a lookup of another structure and a substraction
operation. struct zone is aligned on a node-interleave boundary so the
pointer values of plenty of 0's at the least significant bits of the address.
43 matches
Mail list logo
