Re: How to handle a specific DMA configuration ?

From: Ralf Baechle (ralf_at_linux-mips.org)
Date: 09/30/04

  • Next message: Greg KH: "Re: [PATCH] fix improper use of pci_module_init() in drivers/char/agp/amd64-agp.c" 
    Date:	Thu, 30 Sep 2004 21:59:03 +0200
To: Thomas Petazzoni <thomas.petazzoni@enix.org>

    On Tue, Sep 28, 2004 at 12:08:31PM +0200, Thomas Petazzoni wrote:

    > My physical memory mapping is a bit special : I have 384 MB of
    > memory. The first 256MB are directly connected to the RM9000, while
    > the last 128MB are connected to the Marvell controller. _Only_ the
    > last 128MB are usable for DMA (especially for network traffic). For
    > the moment, Linux only takes care of the first 256MB, but I can change
    > it to take care of the complete physical memory space (384 MB).
    >
    > My problem is the allocation of skbuff. They are allocated using
    > alloc_skb() in net/core/skbuff.c, and uses the "normal" kmalloc()
    > allocator. kmalloc() will allocate memory somewhere in the physical
    > memory space : even if a I allow Linux to allocate memory between
    > 256MB and 384MB, I cannot be sure that it will use memory in this
    > space to allocate skbuff. If skbuff are not allocated in this space,
    > then I can't use DMA to transfer the buffers.
    >
    > As I understand the ZONE_DMA thing, it allows to tell Linux that a
    > physical memory region located between 0 and some value (16 MB on PCs
    > for old ISA cards compatibility) is the only area usable for DMA. How
    > could I declare my 256MB-384MB physical memory reagion to be the only
    > area usable for DMA ? How can I tell the skbuff functions to allocate
    > _only_ DMA-able memory ?

    ZONE_DMA has a system specific meaning. On a PCI system ISA could always
    be exist through a PCI-to-ISA bridge, so you can't just go and give it
    a system specific meaning. It's also needed for PCI devices with a
    less than 32-bit DMA limit; those exist in a rich variety.

    > Moreover, can I make assumptions on the
    > alignement of final data at the bottom of the network stack (my DMA
    > controller doesn't like the 2 byte-aligned things).

    Well, if you put packets on an aligned address you'll later take a bunch
    of missalignment exceptions which are going to severly impact networking
    performance ...

    > At the moment, I see only three solutions. The two first aren't not
    > very satisfying, the third might be a solution, but not perfect
    > neither (and not sure it would work).

    Change the configuration of the board to put the MV memory at the bottom.
    Leave ZONE_DMA what it used to be, < 16MB. Set the ZONE_NORMAL limit to
    128MB. Anything above that is non-dmable will go into ZONE_HIGHMEM.
    See also CONFIG_LIMITED_DMA in 2.6. It works, it has little compatibility
    problems but it's a solution for platform that simply doesn't reflect the
    Linux hw architecture very much ...

      Ralf
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  • Next message: Greg KH: "Re: [PATCH] fix improper use of pci_module_init() in drivers/char/agp/amd64-agp.c"

    Relevant Pages

    • Re: Large arrays (again), problem case for GNAT
      ... >>> allocate a huge array, and then only use some part of it. ... Physical memory is 1000 times more expensive ... The contract of malloc is to return memory ... > Apparently the Linux folks don't think that's the contract. ...
      (comp.lang.ada)
    • Question on the current behaviour of malloc () on Linux
      ... I first asked this question on uClinux mailing list. ... When I run it on my Linux notebook, ... > memory left and you can't free memory because kill can't be called. ... It's true that Linux can allocate memory for application, ...
      (Linux-Kernel)
    • Re: Forgetting stuff is better than dying
      ... In linux, unless it changed more recently than 2.6.11: ... overcommit unless it, um, doesn't. ... See /proc/meminfo for details of total allowed memory commit and current ... CMUCL and SBCL used to just merrily allocate the entire virtual address ...
      (comp.lang.lisp)
    • SBCL performance on OS X
      ... program that just gobbles up memory until the Lisp process dies. ... On Linux, the program dies after ... same program takes 1 minute 13 seconds to allocate the same amount of ...
      (comp.lang.lisp)
    • Re: Assign continusly variable to pointer.
      ... So if it doesnt have enough memory space, how exactly do you expect to ... allocate the memory under any circumstances? ... - Mark Randall ...
      (microsoft.public.vc.language)
    Loading