Hello Scott, Do you know whether this patch is necessary if I were to use alloc_bootmem () (to set aside a region of contiguous physical memory) instead of the kernel parameter "mem=256"? -Steve Lin Scott Wood To 11/18/2010 01:35 cc PM David Gibson , Michael Ellerman , Subject Re: application needs fast access to physical memory On Thu, 18 Nov 2010 10:55:21 -0600 wrote: > Thanks for the replies. > > In the Linux Device Drivers book regarding mmap(), it states: > > Mapping a device means associating a range of user-space addresses to > device memory. > Whenever the program reads or writes in the assigned address range, it > is actually > accessing the device. In the X server example, using mmap allows quick > and easy > access to the video card’s memory. For a performance-critical > application like this, > direct access makes a large difference. > > For whatever reason, mmap() is definitely not quick and does not appear to > be a direct access to device memory. After the application completes a > large write into physical memory (via the pointer returned from mmap()), > the application performs an ioctl() to query whether the data actually > arrived into the memory region. It seems to take some time before the > associated kernel module actually "sees" the data in the physical memory > region. > > There's a few things I should say about this memory region. There's a total > of 512 MB of physical memory. U-Boot passes "mem=256M" as a kernel > parameter to tell Linux to only directly manage the lower 256 MB. The > special region of physical memory that the application is trying to access > is the upper 256 MB of memory not directly managed by Linux. The mmap() > call from the application is: > *memptr = (void *) mmap( NULL, size, PROT_READ | PROT_WRITE, MAP_SHARED, > _fdTerAlloc, (off_t) 0x10000000); Try this patch: http://patchwork.ozlabs.org/patch/68246/ -Scott