Ideas for adding physically contiguous memory support to mmap()??

Ideas for adding physically contiguous memory support to mmap()??

[LUTZ,TODD (HP-Boise,ex1)]

I would like to be able to extend mmap() (in 2.4.2) to support returning
physically contiguous memory as shared memory.

Here are some requirements:

1. Able to specify any size that is a multiple of PAGE_SIZE (not just powers
of 2).

2. Able to specify the size when the application runs (not on the bootline
like the bigphysarea patch).

3. Able to specify sizes larger than 4MB (somewhere between 256MB and 512MB
is probably the max).

4. Preferably add another bit to the flags parameter of mmap(), like
"MAP_CONTIG".

5. It is OK for the call to fail if there isn't enough physically contiguous
memory available (even if there is enough non-contiguous memory available).

After looking at the code, I think I need to...

1. Create a function like alloc_contig_pages() similar to alloc_pages() that
takes a "numpages" parameter instead of "order".

2. Increase MAX_ORDER in mmzone.h to 17.

3. Start at do_mmap_pgoff() and change all the calls down to alloc_pages().

Any suggestions or comments?

-- Thanks,
   Todd Lutz

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux.eu.org/Linux-MM/

Re: Ideas for adding physically contiguous memory support to mmap()??

[Benjamin C.R. LaHaise]

On Tue, 10 Apr 2001, LUTZ,TODD (HP-Boise,ex1) wrote:

> I would like to be able to extend mmap() (in 2.4.2) to support returning
> physically contiguous memory as shared memory.

> Here are some requirements:

> 1. Able to specify any size that is a multiple of PAGE_SIZE (not just powers
> of 2).

First off: why do you need this functionality?  It does not sound like it
provides any significant benefits over the current system once you take
into consideration the effects it will have on memory fragmentation.
Devices that require large chunks of memory are rare and specialised:
reasonable hardware provides support for scatter gather lists (they aren't
difficult to implement in hardware).

		-ben

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux.eu.org/Linux-MM/

Re: Ideas for adding physically contiguous memory support to mmap()??

[Stephen C. Tweedie]

Hi,

On Tue, Apr 10, 2001 at 07:24:12PM -0400, Benjamin C.R. LaHaise wrote:
> On Tue, 10 Apr 2001, LUTZ,TODD (HP-Boise,ex1) wrote:
> 
> > 1. Able to specify any size that is a multiple of PAGE_SIZE (not just powers
> > of 2).
> 
> First off: why do you need this functionality?  It does not sound like it
> provides any significant benefits over the current system once you take
> into consideration the effects it will have on memory fragmentation.

Indeed.  Most of the motivation for large contiguous memory areas in
user space are concerned with cache line colouring and efficient use
of tlbs.  An API for large page support and kernel support for cache
colouring would be nice, but in general the more of this that can be
done opportunistically (without any application API changes), the
better.

Cheers,
 Stephen
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux.eu.org/Linux-MM/

RE: Ideas for adding physically contiguous memory support to mmap ()??

[LUTZ,TODD (HP-Boise,ex1)]

> > I would like to be able to extend mmap() (in 2.4.2) to 
> support returning
> > physically contiguous memory as shared memory.
> 
> > Here are some requirements:
> 
> > 1. Able to specify any size that is a multiple of PAGE_SIZE 
> (not just powers
> > of 2).
> 
> First off: why do you need this functionality?

The short answer...

I have an embedded application that wants to manage most of memory in the
system and wants it to be shared between processes.  The application starts,
determines the amount of free memory, leaves a little for the OS, then
allocates the rest as shared memory.  It needs to be physically contiguous
because not all of our DMAs support scatter-gather.

-- Todd
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux.eu.org/Linux-MM/

RE: Ideas for adding physically contiguous memory support to mmap ()??

[Benjamin C.R. LaHaise]

On Tue, 10 Apr 2001, LUTZ,TODD (HP-Boise,ex1) wrote:

> The short answer...
> 
> I have an embedded application that wants to manage most of memory in the
> system and wants it to be shared between processes.  The application starts,
> determines the amount of free memory, leaves a little for the OS, then
> allocates the rest as shared memory.  It needs to be physically contiguous
> because not all of our DMAs support scatter-gather.

Stop building broken hardware -- seriously!  But if you must, just use the
bigmem patches to reserve a chunk of memory and then mmap it via /dev/mem
(or even boot with a mem= map that leaves memory unused).  That doesn't
require any kernel changes and is much faster to implement. 

		-ben

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux.eu.org/Linux-MM/