Re: [PATCH 3/4] Embed zone_id information within the zonelist->zones pointer

Re: [PATCH 3/4] Embed zone_id information within the zonelist->zones pointer

[Andy Isaacson]

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 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.
> 
> It's essentially only lance, meth, b44 and bcm43xx and lots of s390.
> 
> meth is only used on SGI O2s which are not that slow and unlikely
> to work in tree anyways.
> 
> b44 and bcm43xx run in fast enough new systems to have no trouble
> with copies.

bcm43xx hardware does show up on low-end MIPS boxes (wrt54g anybody?)
that would be sorely hurt by excess copies.

-andy

Re: [PATCH 3/4] Embed zone_id information within the zonelist->zones pointer

[Andi Kleen]

> 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

Re: [PATCH 3/4] Embed zone_id information within the zonelist->zones pointer

[Andy Isaacson]

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 sense and is reassuring, but note that some MIPS boxes
have only part of their physical memory below 1GB; IIRC the
BCM4704/BCM5836 supports up to 512MB of physical memory, with 256MB in
the first GB and the second 256MB located above the 1GB line.  (But it's
been a while since I've run such a machine, so I could be misremembering
the sizes and offsets.)

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...

-andy

Re: [PATCH 3/4] Embed zone_id information within the zonelist->zones pointer

[Andi Kleen]

> 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 your required DMA region is < 4GB.

Besides I'm currently not planning to change mips so it might
stay the same if Ralf prefers that.

-Andi

Re: [PATCH 3/4] Embed zone_id information within the zonelist->zones pointer

[Ralf Baechle]

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.

  Ralf

Re: [PATCH 3/4] Embed zone_id information within the zonelist->zones pointer

[Andi Kleen]

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_DMA in
> an O2-specific device driver.  Will send out patch in separate mail.

Great.

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.

-Andi

Re: [PATCH 3/4] Embed zone_id information within the zonelist->zones pointer

[Ralf Baechle]

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.
> > 
> > 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.
> 
> Great.
> 
> 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.

In case of the O2 the full story is a little more complicated.  The O2 is
not I/O coherent.  That's a well know and handled configuration for the
R5000.  But the R10000 which was never designed for such use will do very
stupid things such as actually performing speculative stores and scribbling
into DMA buffers left and right.  There are two possible workarounds for
this; one is software only the other is using a little CPLD codenamed Juice
on the O2 R10000 board and would require a special memory region for DMA
buffers, so the ZONE_DMA was really there as some sort of future proofing.
But in the end the same arguments as for the Lance apply here.

  Ralf

Re: [PATCH 3/4] Embed zone_id information within the zonelist->zones pointer

[Christoph Lameter]

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.