* allocating a large memory area
@ 2003-03-12 11:28 Hilik Stein
2003-03-13 0:03 ` Ralf Baechle
2003-03-13 0:23 ` Bradley D. LaRonde
0 siblings, 2 replies; 4+ messages in thread
From: Hilik Stein @ 2003-03-12 11:28 UTC (permalink / raw)
To: linux-mips
Hi All
i am building a kernel based fast packet handler which runs on kernel
2.4.20.
my code resides inside the kernel, which is running on sb1 core.
i need to allocate a large memory region for my data (32MB), which is far
beyond what kmalloc can provide for me.
i do not want to use vmalloc, since it will allocate the memory out of
KSEG2, which is too slow and will generate too many exceptions when i
have to access my data randomly.
i was thinking of limiting the linux from accessing the highest physical
32MB by using "mem=224M" kernel command line parameter. this was i
can access my data using 0x8e000000 through KSEG1.
is this safe ? anything i need to consider before moving forward with that
approach ?
thanks
Hilik
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: allocating a large memory area
2003-03-12 11:28 allocating a large memory area Hilik Stein
@ 2003-03-13 0:03 ` Ralf Baechle
2003-03-13 0:23 ` Bradley D. LaRonde
1 sibling, 0 replies; 4+ messages in thread
From: Ralf Baechle @ 2003-03-13 0:03 UTC (permalink / raw)
To: Hilik Stein; +Cc: linux-mips
On Wed, Mar 12, 2003 at 01:28:02PM +0200, Hilik Stein wrote:
> i am building a kernel based fast packet handler which runs on kernel
> 2.4.20.
> my code resides inside the kernel, which is running on sb1 core.
> i need to allocate a large memory region for my data (32MB), which is far
> beyond what kmalloc can provide for me.
> i do not want to use vmalloc, since it will allocate the memory out of
> KSEG2, which is too slow and will generate too many exceptions when i
> have to access my data randomly.
> i was thinking of limiting the linux from accessing the highest physical
> 32MB by using "mem=224M" kernel command line parameter. this was i
> can access my data using 0x8e000000 through KSEG1.
0x8e000000 a KSEG0 address. If you care about performance you don't want
to use KSEG1 :)
> is this safe ? anything i need to consider before moving forward with that
> approach ?
It's the only sensible approach. __get_free_pages()'s limit for allocation
is order 10 by default which would like to PAGE_SIZE * 2^10 = 4MB by
default. Increasing is possible by setting the config symbol
CONFIG_FORCE_MAX_ZONEORDER to the desired value - but that doesn't seem
like a good idea for a one-time allocation as it affects performance and
has heavy fragmentation issues.
kmalloc isn't suitable either. It's got it's own limit of 128k which could
be raised but that doesn't make much sense for other reasons including the
fact that kmalloc is implemented on top of the gfp so the issues in the
last paragraph apply as well.
Ralf
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: allocating a large memory area
2003-03-12 11:28 allocating a large memory area Hilik Stein
2003-03-13 0:03 ` Ralf Baechle
@ 2003-03-13 0:23 ` Bradley D. LaRonde
2003-03-13 0:23 ` Bradley D. LaRonde
1 sibling, 1 reply; 4+ messages in thread
From: Bradley D. LaRonde @ 2003-03-13 0:23 UTC (permalink / raw)
To: Hilik Stein; +Cc: linux-mips
----- Original Message -----
From: "Hilik Stein" <hilik@netvision.net.il>
To: <linux-mips@linux-mips.org>
Sent: Wednesday, March 12, 2003 6:28 AM
Subject: allocating a large memory area
> i need to allocate a large memory region for my data (32MB), which is far
> beyond what kmalloc can provide for me.
> i do not want to use vmalloc, since it will allocate the memory out of
> KSEG2, which is too slow and will generate too many exceptions when i
> have to access my data randomly.
> i was thinking of limiting the linux from accessing the highest physical
> 32MB by using "mem=224M" kernel command line parameter. this was i
> can access my data using 0x8e000000 through KSEG1.
Or put it below the kernel load point.
Or... I've used this trick - define a large array and let the linker make
space for it in .bss. This is convenient since now the kernel has no
special requirement about load address or memory limit and the address can
just be a pointer to the array.
Regards,
Brad
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: allocating a large memory area
2003-03-13 0:23 ` Bradley D. LaRonde
@ 2003-03-13 0:23 ` Bradley D. LaRonde
0 siblings, 0 replies; 4+ messages in thread
From: Bradley D. LaRonde @ 2003-03-13 0:23 UTC (permalink / raw)
To: Hilik Stein; +Cc: linux-mips
----- Original Message -----
From: "Hilik Stein" <hilik@netvision.net.il>
To: <linux-mips@linux-mips.org>
Sent: Wednesday, March 12, 2003 6:28 AM
Subject: allocating a large memory area
> i need to allocate a large memory region for my data (32MB), which is far
> beyond what kmalloc can provide for me.
> i do not want to use vmalloc, since it will allocate the memory out of
> KSEG2, which is too slow and will generate too many exceptions when i
> have to access my data randomly.
> i was thinking of limiting the linux from accessing the highest physical
> 32MB by using "mem=224M" kernel command line parameter. this was i
> can access my data using 0x8e000000 through KSEG1.
Or put it below the kernel load point.
Or... I've used this trick - define a large array and let the linker make
space for it in .bss. This is convenient since now the kernel has no
special requirement about load address or memory limit and the address can
just be a pointer to the array.
Regards,
Brad
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2003-03-13 0:23 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2003-03-12 11:28 allocating a large memory area Hilik Stein
2003-03-13 0:03 ` Ralf Baechle
2003-03-13 0:23 ` Bradley D. LaRonde
2003-03-13 0:23 ` Bradley D. LaRonde
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox