On Mon, 30 Oct 2000, John Levon wrote:
> On Mon, 30 Oct 2000, Richard B. Johnson wrote:
>
> >
> > Hello,
> > How much memory would it be reasonable for kmalloc() to be able
> > to allocate to a module?
> >
> > Oct 30 10:48:31 chaos kernel: kmalloc: Size (524288) too large
> >
> > Using Version 2.2.17, I can't allocate more than 64k! I need
> > to allocate at least 1/2 megabyte and preferably more (like 2 megabytes).
> >
> > There are 256 megabytes of SDRAM available. I don't think it's
> > reasonable that a 1/2 megabyte allocation would fail, especially
> > since it's the first module being installed.
> >
> > The attempt to allocate is memory of type GFP_KERNEL.
>
> Why do you need physically-contiguous memory ? Can you not just use
> vmalloc()/vfree()
>
Well, maybe there is a better way, but the following must happen:
I need a non-paged buffer that has already been allocated, so it is
available during an interrupt.
I get an interrupt, at which time I have to copy up to 4 megabytes
from a memory-mapped PCI window into this RAM. These data represent
a 'snap-shot' of the output of an ADC during the past ~20 us (yes
it's fast). Once I have copied the data, I can then re-enable
the ADC from within the ISR, i.e., allow the image data to change.
The ISR then executes wake_ip_interruptible() to notify a caller
sleeping in poll().
One the caller is awakened, he read()s the device and the data
are copied, using copy_to_user() into its buffers.
Now, I could set up a linked-list of buffers and use vmalloc()
if the buffers were allocated from non-paged RAM. I don't think
they are. These buffers must be present during an interrupt.
However, I could possibly use kmalloc() to initialize a linked-list
so they don't have to be contiguous.
Cheers,
Dick Johnson
Penguin : Linux version 2.2.17 on an i686 machine (801.18 BogoMips).
"Memory is like gasoline. You use it up when you are running. Of
course you get it all back when you reboot..."; Actual explanation
obtained from the Micro$oft help desk.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Tue Oct 31 2000 - 21:00:27 EST