Re: bigphysarea in 2.2

Kevin Fenzi (linker@nightshade.ml.org)
Sat, 11 Apr 1998 15:11:04 -0400 (EDT)


I'de also like to suggest someone put in the option of hard allocating DMA
bufferspace at the kernel command line..

I've got enough RAM that I wouldn't mind giving up 512k at boot just so
that I *know* that there will be ram available for my soundcard, ftape,
floppy, isa nic, etc.. (ok ok I only have a soundcard in this box, but I
used to use FTAPE.. youck)...

On Sat, 11 Apr 1998, Stephen Williams wrote:

>
> I deal with some high-performance image processing hardware. I work in
> gray a lot, and a 200DPI high-speed color scanner is soon to come to
> reality. That said...
>
> David.Mentre@irisa.fr said:
> > With the new kernel memory manager, and if the defragmenting code
> > which is under development works, wouldn't it be more useful to use
> > standard kernel memory allocation. Static allocation like in
> > bigphysarea is more a work-around that a real solution.
>
> It is common for me to need many megabytes per board. In most cases
> they are perfectly capable of scatter-gather, but the huge volume, even
> broken into 4K pages, is usually hard to get, especially after the system
> has been running for a while. (Think loadable modules.)
>
> I do occasionally run into boards that do *not* do scatter-gather, and
> they require lots of contiguous memory. These are typically not high
> quantity, and so not worth the effort of fancy DMA controllers.
>
> It actually strikes me as a bad idea to try to make a memory manager
> that handles these extreme cases at the expense of the normal case. The
> bigphysarea patch offers a different memory allocator intended for doing
> only a few allocations in a big space. This way it doesn't get in the
> way or needlessly complicate the normal allocator. It can also be
> practically turned off without recompiling the kernel.
>
> I think it is reasonable to expect my customers of such extreme hardware
> to set aside memory specifically for the board so that such allocation
> doesn't over-tax the normal allocation mechanism. Putting bigphysarea=foo
> in /etc/lilo.conf is not too much to ask, patching the kernel source or
> restricting them to a specific kernel version, well...
>
> I believe that the bigphysarea patch is worth making a part of the kernel
> as a whole because the Linux kernel is very well suited to these extreme
> tasks that occasionally have special memory requirements. The bigphysarea
> support is simple, yes, and it helps *a lot*.
>
> (The patch can also be modified to put to good use that non-cached memory
> that some computers seem to have.)
>
>
> --
> Steve Williams "The woods are lovely, dark and deep.
> steve@icarus.com But I have promises to keep,
> steve@picturel.com and lines to code before I sleep,
> http://www.picturel.com And lines to code before I sleep."
>
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.rutgers.edu
>

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu