vmalloc limits in PPC kernels ?

vmalloc limits in PPC kernels ?

[vinai]

Hey Folks,

I've been doing a little work trying to update an in-house custom driver
for x86.  We acquired fairly large chunks of data, and we can't afford
to lose any of it. To do this, we reserve a fairly large chunk of memory
in which the data can be stored, as we can't afford system latencies
when writing to disk.  We were able to this in 2.2 without any problems,
but in 2.4, a new "feature" was introduced to x86 that limited how much
memory one can "vmalloc".  I did a quick check, but didn't find anything
in the ppc asm directory.  Do we have such a limit ?

cheers
vinai

"I can't understand people who hate other people based on things like race,
 religion, or sexual orientation.  When you really do get to know a person,
 aren't there so many more worthwhile reasons for despising them ?"

                                        Dennis Miller

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: vmalloc limits in PPC kernels ?

[Matt Porter]

On Thu, Feb 13, 2003 at 02:19:41PM -0600, vinai wrote:
> I've been doing a little work trying to update an in-house custom driver
> for x86.  We acquired fairly large chunks of data, and we can't afford
> to lose any of it. To do this, we reserve a fairly large chunk of memory
> in which the data can be stored, as we can't afford system latencies
> when writing to disk.  We were able to this in 2.2 without any problems,
> but in 2.4, a new "feature" was introduced to x86 that limited how much
> memory one can "vmalloc".  I did a quick check, but didn't find anything
> in the ppc asm directory.  Do we have such a limit ?

All architectures have a limit.  Its size is defined by
VMALLOC_END-VMALLOC_START and further limited by the size of each
preceding allocation (+ a PAGE_SIZE pad) before the allocation in
question.  Allocations also include ioremaps and on some architectures
consistent memory allocations absorb vmalloc space.

You can see the constraints in asm-ppc/pgtable.h.  On PPC, it is
possible to change the default parameters in order to expand the
amount of vmalloc space available.  This is accomplished via
config options under the advanced kernel options menu.  With
PAGE_OFFSET at 0x40000000 and highmem, I've run a system with
nearly 3GB of vmalloc space.

Regards,
--
Matt Porter
porter@cox.net
This is Linux Country. On a quiet night, you can hear Windows reboot.

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: vmalloc limits in PPC kernels ?

[vinai]

Matt,

Thanks much for the information you provided below.  Are there any
pointers/references as to why these changes were actually implemented,
or is it really a case of "the source being the guide" ?  As I said,
this issue is really troubling for us, and I want to see if there is
a "clean" way to circumvent that limit without screwing up the MM
subsystem (at least not too badly :) ...

cheers
vinai

On Thu, 13 Feb 2003, Matt Porter wrote:

> All architectures have a limit.  Its size is defined by
> VMALLOC_END-VMALLOC_START and further limited by the size of each
> preceding allocation (+ a PAGE_SIZE pad) before the allocation in
> question.  Allocations also include ioremaps and on some architectures
> consistent memory allocations absorb vmalloc space.
>
> You can see the constraints in asm-ppc/pgtable.h.  On PPC, it is possible
> to change the default parameters in order to expand the amount of vmalloc
> space available.  This is accomplished via config options under the
> advanced kernel options menu.  With PAGE_OFFSET at 0x40000000 and highmem,
> I've run a system with nearly 3GB of vmalloc space.

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: vmalloc limits in PPC kernels ?

[Matt Porter]

On Fri, Feb 14, 2003 at 11:32:44AM -0600, vinai wrote:
> Matt,
>
> Thanks much for the information you provided below.  Are there any
> pointers/references as to why these changes were actually implemented,
> or is it really a case of "the source being the guide" ?  As I said,
> this issue is really troubling for us, and I want to see if there is
> a "clean" way to circumvent that limit without screwing up the MM
> subsystem (at least not too badly :) ...

No docs beyond mailing list archives (for x86, lkml. for ppc,
-dev/-embedded/#mklinux).  Use the source.

x86's reasons for changes are off-topic here. :) I think you'll
find out that much of the reason had to do with the the transition
from various bigmem hacks to the current highmem solution for large
system memory.  This transition caused i386 to rework their limits
around the pkmap pool for one.  They probably also made their usual
choices around trying to be targetted at the mid-level of ia32
machines.

It's the same thought process that goes into the PPC VM defaults.
The difference is that we have developers that consciously worry
about common embedded application usage.  That led to the VM
tweaking options.

Regards,
--
Matt Porter
porter@cox.net
This is Linux Country. On a quiet night, you can hear Windows reboot.

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/