Re: RFC: Very large allocations for 2.4.x

[Pauline Middelink]

On Tue, 27 Jun 2000 around 13:10:09 -0400, Jeff Garzik wrote:
> Like it or not, there is a need to be able to handle very large,
> contiguous allocations of physical memory.  Frame grabbers and 3D
> drivers both currently use either the "bigphysarea" patch which will
> never make it into the kernel

Why? the ruling against it apply to your mem= patch too. "You need
large continuous memory? Your card is broken." (Linus)

> Yes, I am aware that most applications -shouldn't- use this, but I am
> hoping to convince the readers here that there is still a need to
> support such allocations.  To this end, I propose a simple but flexible
> system.  Comments requested.

I'm all for a large memory allocator. I'm not sure this is
the way to go.

> First, a command line argument ramreserve[1] reserves a region of
> physical memory for our use.  This is better than using mem=XX because
> it does not depend on installed memory size.
> 
> 	# LILO: reserve 10 MB of RAM for large allocs
> 	append="ramreserve=10M"
> 
> Then, when the kernel boots, it grabs a 10M region at the end of
> available memory using reserve_bootmem, and lists that region in
> iomem_resources[2].  From that point, drivers can allocate some or all
> of that region using the existing 2.4.x resource allocation system.

Bad. "At the end of memory", probably means you can't reach it from
a DMA limited or ISA card. Better use alloc_bootmem like bigphysarea
does :)

The only merrit in your proposal I see is using 2.4.0's resource
management, but you need to define an interface to get the
'root' of the area. And how do you handle multiple users?
Oh, isn't the resource system start/end addressed based?
how do you request memory without knowing what start address
it should take? (no, every driver walking the chain of
resources from the exported ramreserve-root is not a
good idea IMO)

Ie..
c0000000 - c0001ffff + ramreserve-root
c0000000 - c00000fff  + card 1
c0001000 - c00001fff  + card 2

> The patch to do this would be very small and nonintrusive -- add a
> single function to process the ramserver cmd line arg.

Did you even look at bigphysarea? Its a patch with one new file,
and only adjusts config.in and Makefile to be compiled in. So
small and non-intrusive would apply there too. It also places
its memory in the iomap so you can look at it :)
[snip]
00100000-03ffffff : System RAM
  00100000-002338a7 : Kernel code
  002338a8-00249a07 : Kernel data
c02a4000-c06a4000 : Bigphysarea
[snip]

> If people are agreeable to this, I'll send a patch towards Linus.  Let's
> put an end to the hacks like bigphysarea for frame grabbers or using
> mem=XX to reserve memory for 3D GLX drivers.

I don't see the hack part of bigphysarea. It nicely works with the
available bootmem technics to allocate the needed memory, and is
allowing multiple users to use it. It exists for a few years and
has a ready established API.

    Met vriendelijke groet,
        Pauline Middelink
-- 
PGP Key fingerprint = DE 6B D0 D9 19 AD A7 A0  58 A3 06 9D B6 34 39 E2
For more details look at my website http://www.polyware.nl/~middelink