RE: Reserving large amounts of RAM for busmastering PCI card.
Please CC [email protected] on your replies.
I have an IBM P390 card, which will use up to 512M of contiguous
RAM for "expanded storage", which can be thought of as a swap device.
On the 2.2 kernels I modified setup.c to parse RESERVE=nnnM and take
that amount off the top of the bios-reported memory size. My module
then picks the address and size up from a place where I left them at
boot time.
Since the 2.4 kernels introduce the e820map structure, I'd like to
plug into that infrastructure, and create a new type memory segment
for this storage (I envisage having more than one segment), but in the
2.4.4 kernel (which I am forced to remain with for quite a while) it
seems not to be used apart from set up at boot time.
I'm quite happy to do the work to generalise this, if I could get a
pointer as to the direction that is envisaged.
Thanks,
j. [email protected]
> Since the 2.4 kernels introduce the e820map structure, I'd like to
> plug into that infrastructure, and create a new type memory segment
> for this storage (I envisage having more than one segment), but in the
> 2.4.4 kernel (which I am forced to remain with for quite a while) it
> seems not to be used apart from set up at boot time.
Stop reinventing the wheel and take Matt & Pauline's bigphisarea.
http://www.polyware.nl/~middelink/patch/bigphysarea-2.4.4.tar.gz
-- Pete
Pete Zaitcev wrote:
>
> > Since the 2.4 kernels introduce the e820map structure, I'd like to
> > plug into that infrastructure, and create a new type memory segment
> > for this storage (I envisage having more than one segment), but in the
> > 2.4.4 kernel (which I am forced to remain with for quite a while) it
> > seems not to be used apart from set up at boot time.
>
> Stop reinventing the wheel and take Matt & Pauline's bigphisarea.
> http://www.polyware.nl/~middelink/patch/bigphysarea-2.4.4.tar.gz
Is bigphysarea needed in 2.4? You have alloc_bootmem...
--
Jeff Garzik | "I use Mandrake Linux for the same reason I turn
Building 1024 | the light switch on and off 17 times before leaving
MandrakeSoft | the room.... If I don't my family will die."
| -- slashdot.org comment
> > > Since the 2.4 kernels introduce the e820map structure, I'd like to
> > > plug into that infrastructure, and create a new type memory segment
> > > for this storage (I envisage having more than one segment), but in the
> > > 2.4.4 kernel (which I am forced to remain with for quite a while) it
> > > seems not to be used apart from set up at boot time.
> >
> > Stop reinventing the wheel and take Matt & Pauline's bigphisarea.
> > http://www.polyware.nl/~middelink/patch/bigphysarea-2.4.4.tar.gz
>
> Is bigphysarea needed in 2.4? You have alloc_bootmem...
I thought bigphisarea allowed to unload and reload modules,
at least I used it that way with C-cube MPEG board. Makes
for faster tests.
-- Pete
Pete Zaitcev wrote:
>
> > > > Since the 2.4 kernels introduce the e820map structure, I'd like to
> > > > plug into that infrastructure, and create a new type memory segment
> > > > for this storage (I envisage having more than one segment), but in the
> > > > 2.4.4 kernel (which I am forced to remain with for quite a while) it
> > > > seems not to be used apart from set up at boot time.
> > >
> > > Stop reinventing the wheel and take Matt & Pauline's bigphisarea.
> > > http://www.polyware.nl/~middelink/patch/bigphysarea-2.4.4.tar.gz
> >
> > Is bigphysarea needed in 2.4? You have alloc_bootmem...
>
> I thought bigphisarea allowed to unload and reload modules,
> at least I used it that way with C-cube MPEG board. Makes
> for faster tests.
AFAICS this is only useful to developers, not end users, yes?
Memory will get fragmented if done at some time other than boot, so
module loads will randomly fail based on conditions unrelated to the
module at hand. It's not a reliable operation, as a module...
--
Jeff Garzik | "I use Mandrake Linux for the same reason I turn
Building 1024 | the light switch on and off 17 times before leaving
MandrakeSoft | the room.... If I don't my family will die."
| -- slashdot.org comment
On Thu, 26 Jul 2001 around 12:32:18 -0400, Jeff Garzik wrote:
> Pete Zaitcev wrote:
> >
> > > > > Since the 2.4 kernels introduce the e820map structure, I'd like to
> > > > > plug into that infrastructure, and create a new type memory segment
> > > > > for this storage (I envisage having more than one segment), but in the
> > > > > 2.4.4 kernel (which I am forced to remain with for quite a while) it
> > > > > seems not to be used apart from set up at boot time.
> > > >
> > > > Stop reinventing the wheel and take Matt & Pauline's bigphisarea.
> > > > http://www.polyware.nl/~middelink/patch/bigphysarea-2.4.4.tar.gz
> > >
> > > Is bigphysarea needed in 2.4? You have alloc_bootmem...
> >
> > I thought bigphisarea allowed to unload and reload modules,
> > at least I used it that way with C-cube MPEG board. Makes
> > for faster tests.
>
> AFAICS this is only useful to developers, not end users, yes?
>
> Memory will get fragmented if done at some time other than boot, so
> module loads will randomly fail based on conditions unrelated to the
> module at hand. It's not a reliable operation, as a module...
No, bigphysarea takes it memory from bootmem not from kmalloc, and
gives it out to requesters of contingious memory.
When used with modules (like my zoran driver, it alloc at driver
open time and frees the memory at driver close time, giving the
user a second chance at nicely grabbed pictures :) )
Met vriendelijke groet,
Pauline Middelink
--
GPG Key fingerprint = 2D5B 87A7 DDA6 0378 5DEA BD3B 9A50 B416 E2D0 C3C2
For more details look at my website http://www.polyware.nl/~middelink