FW: 2.4.9/2.4.18 max kernel allocation size

FW: 2.4.9/2.4.18 max kernel allocation size

[Ofer Raz]

-----Original Message-----
From: Ofer Raz [mailto:oraz@checkpoint.com]
Sent: Tuesday, October 08, 2002 2:19 PM
To: 'linux-kernel-owner@vger.kernel.org'
Subject: 2.4.9/2.4.18 max kernel allocation size


I'm trying to obtain the largest kernel allocation possible using vmalloc.

I have tested both Linux 2.4.9-7 and 2.4.18-10 max kernel allocation using
vmalloc on Intel platform with different physical memory configurations.
>From my experience, playing with the Virtual/Physical memory split issues
different results (which makes sense)

Following are the results on 2.4.9-7 when the 4GB highmem config option is
set:

Config Option	Physical Memory	Max Allocation
CONFIG_1GB		512MB			400
			1024MB		900
			1536MB		1400
			2048MB		981

CONFIG_2GB		512MB			400
			1024MB		900
			1536MB		461
			2048MB		VFS Panic on boot

CONFIG_3GB		512MB			400
			1024MB		85
			1536MB		VFS Panic on boot
			2048MB		VFS Panic on boot

Please note that CONFIG_3GB is the default and results 85MB max allocation
for 1GB machine.

For my surprise, I have discovered that the CONFIG_1GB/CONFIG_2GB/CONFIG_3GB
configuration options were removed from 2.4.18-10, it seems that the kernel
is set for the CONFIG_3GB option (by looking at the PAGE_OFFSET mask
(0xc0000000)).

Any idea how can I make the kernel allocation on 2.4.18-10 larger than 85MB
on 1GB machine?

Cheers,
	Ofer

Re: FW: 2.4.9/2.4.18 max kernel allocation size

[Arjan van de Ven]

[-- Attachment #1: Type: text/plain, Size: 708 bytes --]

On Tue, 2002-10-08 at 17:19, Ofer Raz wrote:
> 
> 
> -----Original Message-----
> From: Ofer Raz [mailto:oraz@checkpoint.com]
> Sent: Tuesday, October 08, 2002 2:19 PM
> To: 'linux-kernel-owner@vger.kernel.org'
> Subject: 2.4.9/2.4.18 max kernel allocation size
> 
> 
> I'm trying to obtain the largest kernel allocation possible using vmalloc

anything you can get > 64Mb on x86 is pure luck (eg you are lucky in
your choice of PCI cards)

> 
> Any idea how can I make the kernel allocation on 2.4.18-10 larger than 85MB
> on 1GB machine?
>
Please give a pointer to the source of your code so that everybody here
can see what you are trying to do and how to fix it to do it different


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: FW: 2.4.9/2.4.18 max kernel allocation size

[Arjan van de Ven]

On Tue, Oct 08, 2002 at 06:17:17PM +0200, Ofer Raz wrote:
> The following code was used in kernel module & called from IOCTL context in
> order to test the max allocation size possible:

I think you misunderstood. I was asking for the source
of the PROBLEM you
were having, not the test. You are doing something wrong for needing
such a huge vmalloc area, but without the source (it
is gpl code, right?) nobody can do suggestions on how to improve your code.

> 
> #define BLOCK_SIZE xxx
> 
> for (size = BLOCK_SIZE; size; size--)
> {
>     tmp = vmalloc(size * 1024 * 1024);
> 
>     if (tmp)
>     {
>         printk("Allocation of %dMB bytes succeeded!\n", size);
>         vfree(tmp);
>         break;
>     }
> }
> 
y

RE: FW: 2.4.9/2.4.18 max kernel allocation size

[Ofer Raz]

I've done some additional testing.
In order to avoid huge allocations, I've tried allocating 100 blocks of 3MB
each on 2.4.18-10 using vmalloc.

On 1GB physical memory machine I can allocate only 80MB.
When adding memory limit to grub.conf (mem=999M) I get 900MB.

- Ofer


-----Original Message-----
From: linux-kernel-owner@vger.kernel.org
[mailto:linux-kernel-owner@vger.kernel.org]On Behalf Of Arjan van de Ven
Sent: Tuesday, October 08, 2002 6:19 PM
To: Ofer Raz
Cc: 'Arjan van de Ven'; wagnerjd@prodigy.net; linux-kernel@vger.kernel.org
Subject: Re: FW: 2.4.9/2.4.18 max kernel allocation size


On Tue, Oct 08, 2002 at 06:17:17PM +0200, Ofer Raz wrote:
> The following code was used in kernel module & called from IOCTL context
in
> order to test the max allocation size possible:

I think you misunderstood. I was asking for the source
of the PROBLEM you
were having, not the test. You are doing something wrong for needing
such a huge vmalloc area, but without the source (it
is gpl code, right?) nobody can do suggestions on how to improve your code.

>
> #define BLOCK_SIZE xxx
>
> for (size = BLOCK_SIZE; size; size--)
> {
>     tmp = vmalloc(size * 1024 * 1024);
>
>     if (tmp)
>     {
>         printk("Allocation of %dMB bytes succeeded!\n", size);
>         vfree(tmp);
>         break;
>     }
> }
>
y
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: 2.4.9/2.4.18 max kernel allocation size

[Joseph D. Wagner]

I might be thinking of something totally different than what you're
talking about, but here it goes:

Change line 18 of mmzone.h from:
	#define MAX_ORDER 10
	to
	#define MAX_ORDER 24

This allows larger contiguous chunks of memory to be allocated, up to
32GB.

I'd be very appreciative if you could send me back whatever statistics
you get as a result of this change.  (To be honest, I'm not a good
kernel hacker, and I wanted to gather statistics on this for some time
but don't know how.)

Thanks in advance.

Joseph Wagner

-----Original Message-----
From: linux-kernel-owner@vger.kernel.org
[mailto:linux-kernel-owner@vger.kernel.org] On Behalf Of Ofer Raz
Sent: Tuesday, October 08, 2002 10:19 AM
To: linux-kernel@vger.kernel.org
Subject: FW: 2.4.9/2.4.18 max kernel allocation size



-----Original Message-----
From: Ofer Raz [mailto:oraz@checkpoint.com]
Sent: Tuesday, October 08, 2002 2:19 PM
To: 'linux-kernel-owner@vger.kernel.org'
Subject: 2.4.9/2.4.18 max kernel allocation size


I'm trying to obtain the largest kernel allocation possible using
vmalloc.

I have tested both Linux 2.4.9-7 and 2.4.18-10 max kernel allocation
using
vmalloc on Intel platform with different physical memory configurations.
>From my experience, playing with the Virtual/Physical memory split
issues
different results (which makes sense)

Following are the results on 2.4.9-7 when the 4GB highmem config option
is
set:

Config Option	Physical Memory	Max Allocation
CONFIG_1GB		512MB			400
			1024MB		900
			1536MB		1400
			2048MB		981

CONFIG_2GB		512MB			400
			1024MB		900
			1536MB		461
			2048MB		VFS Panic on boot

CONFIG_3GB		512MB			400
			1024MB		85
			1536MB		VFS Panic on boot
			2048MB		VFS Panic on boot

Please note that CONFIG_3GB is the default and results 85MB max
allocation
for 1GB machine.

For my surprise, I have discovered that the
CONFIG_1GB/CONFIG_2GB/CONFIG_3GB
configuration options were removed from 2.4.18-10, it seems that the
kernel
is set for the CONFIG_3GB option (by looking at the PAGE_OFFSET mask
(0xc0000000)).

Any idea how can I make the kernel allocation on 2.4.18-10 larger than
85MB
on 1GB machine?

Cheers,
	Ofer

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel"
in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: 2.4.9/2.4.18 max kernel allocation size

[Gianni Tedesco]

[-- Attachment #1: Type: text/plain, Size: 706 bytes --]

On Tue, 2002-10-08 at 16:35, Joseph D. Wagner wrote:
> I might be thinking of something totally different than what you're
> talking about, but here it goes:
> 
> Change line 18 of mmzone.h from:
> 	#define MAX_ORDER 10
> 	to
> 	#define MAX_ORDER 24
> 
> This allows larger contiguous chunks of memory to be allocated, up to
> 32GB.

He's using vmalloc, so I assume he doesn't need physically contiguous
memory, rather virtually contigous. This code won't change a thing for
his vmalloc() calls AFAICS.

-- 
// Gianni Tedesco (gianni at ecsc dot co dot uk)
lynx --source www.scaramanga.co.uk/gianni-at-ecsc.asc | gpg --import
8646BE7D: 6D9F 2287 870E A2C9 8F60 3A3C 91B5 7669 8646 BE7D

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 232 bytes --]