* Page Allocation Failure, Why?? Bug in kernel??
@ 2006-06-01 9:26 Abu M. Muttalib
2006-06-01 13:25 ` Paulo Marques
0 siblings, 1 reply; 11+ messages in thread
From: Abu M. Muttalib @ 2006-06-01 9:26 UTC (permalink / raw)
To: linux-kernel
[-- Attachment #1: Type: text/plain, Size: 329 bytes --]
Hi,
I tried to run an application, try-sound.c. In the course of the run of the
application I repeatedly got page allocation failure, despite the fact that
enough pages are free. Why this is so, is it a bug in mm subsystem of Linux
kernel 2.6.13?
Any pointer to help understand this behavior will be highly appreciated.
~Abu.
[-- Attachment #2: Page_Allocation_Failure.tar.bz2 --]
[-- Type: application/octet-stream, Size: 28486 bytes --]
[-- Attachment #3: try-sound.c --]
[-- Type: application/octet-stream, Size: 7611 bytes --]
#include <stdio.h>
#include <malloc.h>
#include <fcntl.h>
// YoKu 20-10-04 for PMU
#include <linux/i2c.h>
#include <linux/i2c-dev.h>
// YoKu
#define PAGES 900
#define SIGPAGE 4096
#define REFERESH 0
// LCD VDIG_1
#define LCD 2
// LCD_BACKLIGHT CURR1
#define LCD_BACKLIGHT 3
#define I2C_DEV "/dev/i2c-0" // I2C Device File
#define PMU_CHARGER "/dev/PMU_CHARGER"
#define WAVE_PIPE "/tmp/WAVE_PIPE"
#define PMU_ADDR 0x41 // PMU Write Address
#define POWER_CONTROL 9
#define ON 1
#define OFF 0
#define LCD_ON_MASK 0x04 // 0000 0100 POWER_CONTROL
#define LCD_BACKLIGHT_ON_MASK 0x04 // 0000 0100 CURR_CONTROL
#define CURR_CONTROL 40
#define CURR_MODE 41
int fdI2C;
unsigned char gbyLCDBackOn = 1;
fn_SwitchDev(unsigned char byDev, unsigned char byOp)
{
__s16 byPresent_val;
if ( byDev == LCD )
{
if( (byPresent_val = i2c_smbus_read_byte_data(fdI2C , POWER_CONTROL)) < 0)
{
perror("\nfn_SwitchDev: I2C POWER_CONTROL Read Fail") ;
}
else
{
if ( byOp == ON )
{
byPresent_val |= LCD_ON_MASK;
#ifdef MAIN_DEBUG
printf("\nPMU: Switching LCD ON");
#endif
}
else
{
byPresent_val &= ~LCD_ON_MASK;
#ifdef MAIN_DEBUG
printf("\nPMU: Switching LCD OFF");
#endif
}
if(i2c_smbus_write_byte_data( fdI2C, POWER_CONTROL, byPresent_val ) < 0)
{
perror("\nfn_SwitchDev: I2C POWER_CONTROL write Fail") ;
}
}
}
else if ( byDev == LCD_BACKLIGHT )
{
if( (byPresent_val = i2c_smbus_read_byte_data( fdI2C , CURR_CONTROL )) < 0)
{
perror("\nfn_SwitchDev: I2C CURR_CONTROL Read Fail") ;
}
else
{
//pthread_mutex_lock(&_mutgbyLCDBackOn);
if ( byOp == ON )
{
byPresent_val |= LCD_BACKLIGHT_ON_MASK;
#ifdef MAIN_DEBUG
printf("\nPMU: Switching LCD BACKLIGHT ON");
#endif
if(i2c_smbus_write_byte_data( fdI2C, CURR_CONTROL, byPresent_val ) < 0)
perror("\nfn_SwitchDev: I2C CURR_CONTROL write Fail") ;
else
gbyLCDBackOn = 1;
}
else
{
byPresent_val &= ~LCD_BACKLIGHT_ON_MASK;
#ifdef MAIN_DEBUG
printf("\nPMU: Switching LCD BACKLIGHT OFF");
#endif
if(i2c_smbus_write_byte_data( fdI2C, CURR_CONTROL, byPresent_val ) < 0)
perror("\nfn_SwitchDev: I2C CURR_CONTROL write Fail") ;
else
gbyLCDBackOn = 0;
}
//pthread_mutex_unlock(&_mutgbyLCDBackOn);
}
}
}
int main()
{
int i=-1;
static unsigned int cntr = 0 ;
char *poarray,*p2=NULL;
system("cat /proc/meminfo");
for (i=0;i<PAGES;i++)
{
poarray=(char*)malloc(SIGPAGE);
memset(poarray, '\0', SIGPAGE);
if(poarray==NULL)
{
printf("\nError in allocating\n");
exit(1);
}
}
if( (fdI2C = open(I2C_DEV,O_RDWR)) < 0 ) // Open I2C Device
{
perror("\nMAIN: Cannot open I2C device\n") ;
}
else
{
// Write 'PMU Write addr' to I2C Device
if (ioctl(fdI2C,I2C_SLAVE,PMU_ADDR) < 0)
{
perror("\nMAIN: I2C PMU_ADDR Write Fail");
}
printf("\nMAIN: I2C PMU_ADDR Write Success.fdI2c = %d" ,fdI2C );
}
fn_SwitchDev(LCD, 1);
fn_SwitchDev(LCD_BACKLIGHT, 1);
while(1)
{
cntr ++ ;
fn_SwitchDev(LCD_BACKLIGHT, 0);
printf("\nREMOVING MODULES Ittr=%d \n" , cntr);
sleep(REFERESH);
system("cat /proc/meminfo");
system("cat /proc/buddyinfo");
sleep(REFERESH);
system("rmmod snd-pcm-oss");
sleep(REFERESH);
system("cat /proc/meminfo");
system("cat /proc/buddyinfo");
sleep(REFERESH);
system("rmmod snd-mixer-oss");
sleep(REFERESH);
system("cat /proc/buddyinfo");
system("cat /proc/meminfo");
sleep(REFERESH);
system("rmmod snd-pxa2xx-ac97");
sleep(REFERESH);
system("cat /proc/buddyinfo");
system("cat /proc/meminfo");
sleep(REFERESH);
system("rmmod snd-pxa2xx-pcm");
sleep(REFERESH);
system("cat /proc/buddyinfo");
system("cat /proc/meminfo");
sleep(REFERESH);
system("rmmod snd-ac97-codec");
sleep(REFERESH);
system("cat /proc/buddyinfo");
system("cat /proc/meminfo");
sleep(REFERESH);
system("rmmod snd-pcm");
sleep(REFERESH);
system("cat /proc/buddyinfo");
system("cat /proc/meminfo");
sleep(REFERESH);
system("rmmod snd-page-alloc");
sleep(REFERESH);
system("cat /proc/buddyinfo");
system("cat /proc/meminfo");
sleep(REFERESH);
system("rmmod snd-timer");
sleep(REFERESH);
system("cat /proc/buddyinfo");
system("cat /proc/meminfo");
sleep(REFERESH);
system("rmmod snd");
sleep(REFERESH);
system("cat /proc/buddyinfo");
system("cat /proc/meminfo");
sleep(REFERESH);
system("rmmod soundcore");
sleep(REFERESH);
system("cat /proc/buddyinfo");
system("cat /proc/meminfo");
sleep(REFERESH);
sleep(2);
fn_SwitchDev(LCD_BACKLIGHT, 1);
p2=(char*)malloc(100);
if(p2 == NULL)
{
printf("OOM PROBLEM");
}
system("lsmod");
system("cat /proc/buddyinfo");
system("cat /proc/meminfo");
// system("echo 150 >/proc/sys/pm/suspend");
system("cat /proc/meminfo");
printf("\nInserting Modules\n");
system("/sbin/insmod /lib/modules/2.6.13/alsa/soundcore.ko");
sleep(REFERESH);
system("cat /proc/buddyinfo");
system("cat /proc/meminfo");
sleep(REFERESH);
system("/sbin/insmod /lib/modules/2.6.13/alsa/snd.ko");
sleep(REFERESH);
system("cat /proc/buddyinfo");
system("cat /proc/meminfo");
sleep(REFERESH);
system("/sbin/insmod /lib/modules/2.6.13/alsa/snd-timer.ko");
sleep(REFERESH);
system("cat /proc/buddyinfo");
system("cat /proc/meminfo");
sleep(REFERESH);
system("/sbin/insmod /lib/modules/2.6.13/alsa/snd-page-alloc.ko");
sleep(REFERESH);
system("cat /proc/buddyinfo");
system("cat /proc/meminfo");
sleep(REFERESH);
system("/sbin/insmod /lib/modules/2.6.13/alsa/snd-pcm.ko");
sleep(REFERESH);
system("cat /proc/buddyinfo");
system("cat /proc/meminfo");
sleep(REFERESH);
system("/sbin/insmod /lib/modules/2.6.13/alsa/snd-ac97-codec.ko");
sleep(REFERESH);
system("cat /proc/buddyinfo");
system("cat /proc/meminfo");
sleep(REFERESH);
system("/sbin/insmod /lib/modules/2.6.13/alsa/snd-pxa2xx-pcm.ko");
sleep(REFERESH);
system("cat /proc/buddyinfo");
system("cat /proc/meminfo");
sleep(REFERESH);
system("/sbin/insmod /lib/modules/2.6.13/alsa/snd-pxa2xx-ac97.ko");
sleep(REFERESH);
system("cat /proc/buddyinfo");
system("cat /proc/meminfo");
sleep(REFERESH);
system("/sbin/insmod /lib/modules/2.6.13/alsa/snd-mixer-oss.ko");
sleep(REFERESH);
system("cat /proc/buddyinfo");
system("cat /proc/meminfo");
sleep(REFERESH);
system("/sbin/insmod /lib/modules/2.6.13/alsa/snd-pcm-oss.ko");
sleep(REFERESH);
system("cat /proc/buddyinfo");
system("rmmod linuxdrv");
sleep(REFERESH);
system("cat /proc/buddyinfo");
system("cat /proc/meminfo");
system("/sbin/insmod /root/linuxdrv.ko");
system("cat /proc/meminfo");
system("lsmod");
system("cat /proc/buddyinfo");
sleep(REFERESH);
free(p2);
p2 = NULL;
}
}
^ permalink raw reply [flat|nested] 11+ messages in thread* Re: Page Allocation Failure, Why?? Bug in kernel??
2006-06-01 9:26 Page Allocation Failure, Why?? Bug in kernel?? Abu M. Muttalib
@ 2006-06-01 13:25 ` Paulo Marques
2006-06-01 13:51 ` Abu M. Muttalib
0 siblings, 1 reply; 11+ messages in thread
From: Paulo Marques @ 2006-06-01 13:25 UTC (permalink / raw)
To: Abu M. Muttalib; +Cc: linux-kernel
Abu M. Muttalib wrote:
> Hi,
Hi,
> I tried to run an application, try-sound.c. In the course of the run of the
> application I repeatedly got page allocation failure, despite the fact that
> enough pages are free. Why this is so, is it a bug in mm subsystem of Linux
> kernel 2.6.13?
>
> Any pointer to help understand this behavior will be highly appreciated.
If you're expecting kernel developers to unpack your text file and read
through 40555(!!!) lines of text to find out what's wrong...
Please try to explain your problem better with some before / after
comparisons that fit nicely into an email and point out specifically
where you think it went wrong. Also describe what you're trying to do
and what kind of hardware you're using.
For more detailed information on how to report kernel bugs, please read
the file REPORTING-BUGS in the main kernel source directory.
Please don't see this as a "we don't care" message. If the kernel has
indeed a bug we very much do care! We just can't go through thousands of
lines of text to try to understand what the problem is... :(
--
Paulo Marques - www.grupopie.com
Pointy-Haired Boss: I don't see anything that could stand in our way.
Dilbert: Sanity? Reality? The laws of physics?
^ permalink raw reply [flat|nested] 11+ messages in thread* RE: Page Allocation Failure, Why?? Bug in kernel??
2006-06-01 13:25 ` Paulo Marques
@ 2006-06-01 13:51 ` Abu M. Muttalib
2006-06-01 14:59 ` Martin J. Bligh
0 siblings, 1 reply; 11+ messages in thread
From: Abu M. Muttalib @ 2006-06-01 13:51 UTC (permalink / raw)
To: Paulo Marques; +Cc: linux-kernel
Hi,
I am sorry to cause inconvenience. To put the doubts concisely, I am doing
the following:
I am removing the sound driver (shipped with kernel 2.6.13) and then
inserting the same. This all I am doing inside an infinite loop. Before this
I have reserved and used (setting the same with memset) some 900 pages to
simulate an application environment. I am running this application on Linux
2.6.13 on an ARM based target. During the course of the run I get the
following page allocation error:
----------------------------------------------------------------------------
---------------------------------------------------------------insmod: page
allocation failure. order:5, mode:0xd0
Mem-info:
DMA per-cpu:
cpu 0 hot: low 2, high 6, batch 1 used:5
cpu 0 cold: low 0, high 2, batch 1 used:1
Normal per-cpu: empty
HighMem per-cpu: empty
Free pages: 824kB (0kB HighMem)
Active:1625 inactive:291 dirty:0 writeback:0 unstable:0 free:206 slab:483
mapped:1382 pagetables:43
DMA free:824kB min:512kB low:640kB high:768kB active:6500kB inactive:1164kB
present:16384kB pages_scanned:0 all_unreclaimable? no
lowmem_reserve[]: 0 0 0
Normal free:0kB min:0kB low:0kB high:0kB active:0kB inactive:0kB present:0kB
pages_scanned:0 all_unreclaimable? no
lowmem_reserve[]: 0 0 0
HighMem free:0kB min:128kB low:160kB high:192kB active:0kB inactive:0kB
present:0kB pages_scanned:0 all_unreclaimable? no
lowmem_reserve[]: 0 0 0
DMA: 52*4kB 25*8kB 4*16kB 3*32kB 2*64kB 1*128kB 0*256kB 0*512kB 0*1024kB =
824kB
Normal: empty
HighMem: empty
Swap cache: add 0, delete 0, find 0/0, race 0+0
Free swap = 0kB
Total swap = 0kB
Free swap: 0kB
4096 pages of RAM
422 free pages
593 reserved pages
483 slab pages
297 pages shared
0 pages swap cached
----------------------------------------------------------------------------
---------------------------------------------------------------
The meminfo and buddyinfo, before the said run of application, is as
follows:
----------------------------------------------------------------------------
---------------------------------------------------------------
Node 0, zone DMA 15 20 4 3 2 2 0
0 0
MemTotal: 14296 kB
MemFree: 760 kB
Buffers: 224 kB
Cached: 2544 kB
SwapCached: 0 kB
Active: 7340 kB
Inactive: 520 kB
HighTotal: 0 kB
HighFree: 0 kB
LowTotal: 14296 kB
LowFree: 760 kB
SwapTotal: 0 kB
SwapFree: 0 kB
Dirty: 0 kB
Writeback: 0 kB
Mapped: 5556 kB
Slab: 1932 kB
CommitLimit: 7148 kB
Committed_AS: 9148 kB
PageTables: 172 kB
VmallocTotal: 630784 kB
VmallocUsed: 262560 kB
VmallocChunk: 366588 kB
----------------------------------------------------------------------------
---------------------------------------------------------------
The meminfo and buddyinfo, after the said run of application, is as follows:
----------------------------------------------------------------------------
---------------------------------------------------------------
MemTotal: 14296 kB
MemFree: 936 kB
Buffers: 144 kB
Cached: 2440 kB
SwapCached: 0 kB
Active: 7308 kB
Inactive: 368 kB
HighTotal: 0 kB
HighFree: 0 kB
LowTotal: 14296 kB
LowFree: 936 kB
SwapTotal: 0 kB
SwapFree: 0 kB
Dirty: 0 kB
Writeback: 0 kB
Mapped: 5556 kB
Slab: 1932 kB
CommitLimit: 7148 kB
Committed_AS: 9148 kB
PageTables: 172 kB
VmallocTotal: 630784 kB
VmallocUsed: 262560 kB
VmallocChunk: 366588 kB
Node 0, zone DMA 21 32 4 3 2 2 0
0 0
----------------------------------------------------------------------------
---------------------------------------------------------------
I fail to understand that despite the fact the system has enough memory, it
is not allocating the same to application. Why? Is it possibly a bug in
kernel?
Thanks and anticipation.
~Abu.
-----Original Message-----
From: Paulo Marques [mailto:pmarques@grupopie.com]
Sent: Thursday, June 01, 2006 6:56 PM
To: Abu M. Muttalib
Cc: linux-kernel@vger.kernel.org
Subject: Re: Page Allocation Failure, Why?? Bug in kernel??
Abu M. Muttalib wrote:
> Hi,
Hi,
> I tried to run an application, try-sound.c. In the course of the run of
the
> application I repeatedly got page allocation failure, despite the fact
that
> enough pages are free. Why this is so, is it a bug in mm subsystem of
Linux
> kernel 2.6.13?
>
> Any pointer to help understand this behavior will be highly appreciated.
If you're expecting kernel developers to unpack your text file and read
through 40555(!!!) lines of text to find out what's wrong...
Please try to explain your problem better with some before / after
comparisons that fit nicely into an email and point out specifically
where you think it went wrong. Also describe what you're trying to do
and what kind of hardware you're using.
For more detailed information on how to report kernel bugs, please read
the file REPORTING-BUGS in the main kernel source directory.
Please don't see this as a "we don't care" message. If the kernel has
indeed a bug we very much do care! We just can't go through thousands of
lines of text to try to understand what the problem is... :(
--
Paulo Marques - www.grupopie.com
Pointy-Haired Boss: I don't see anything that could stand in our way.
Dilbert: Sanity? Reality? The laws of physics?
^ permalink raw reply [flat|nested] 11+ messages in thread* Re: Page Allocation Failure, Why?? Bug in kernel??
2006-06-01 13:51 ` Abu M. Muttalib
@ 2006-06-01 14:59 ` Martin J. Bligh
2006-06-02 6:26 ` Abu M. Muttalib
0 siblings, 1 reply; 11+ messages in thread
From: Martin J. Bligh @ 2006-06-01 14:59 UTC (permalink / raw)
To: Abu M. Muttalib; +Cc: Paulo Marques, linux-kernel
Abu M. Muttalib wrote:
> Hi,
>
> I am sorry to cause inconvenience. To put the doubts concisely, I am doing
> the following:
>
> I am removing the sound driver (shipped with kernel 2.6.13) and then
> inserting the same. This all I am doing inside an infinite loop. Before this
> I have reserved and used (setting the same with memset) some 900 pages to
> simulate an application environment. I am running this application on Linux
> 2.6.13 on an ARM based target. During the course of the run I get the
> following page allocation error:
> ----------------------------------------------------------------------------
> ---------------------------------------------------------------insmod: page
> allocation failure. order:5, mode:0xd0
Order 5 allocations will never work reliably, except possibly at boot.
We don't have 32 contig pages to give you - fragmentation.
M.
^ permalink raw reply [flat|nested] 11+ messages in thread
* RE: Page Allocation Failure, Why?? Bug in kernel??
2006-06-01 14:59 ` Martin J. Bligh
@ 2006-06-02 6:26 ` Abu M. Muttalib
2006-06-02 7:05 ` Jesper Juhl
0 siblings, 1 reply; 11+ messages in thread
From: Abu M. Muttalib @ 2006-06-02 6:26 UTC (permalink / raw)
To: Martin J. Bligh; +Cc: Paulo Marques, linux-kernel
Hi,
That's precisely I want to say. The PAGES are available but they are not
allocated to process. Why??
~Abu.
-----Original Message-----
From: Martin J. Bligh [mailto:mbligh@mbligh.org]
Sent: Thursday, June 01, 2006 8:29 PM
To: Abu M. Muttalib
Cc: Paulo Marques; linux-kernel@vger.kernel.org
Subject: Re: Page Allocation Failure, Why?? Bug in kernel??
Abu M. Muttalib wrote:
> Hi,
>
> I am sorry to cause inconvenience. To put the doubts concisely, I am doing
> the following:
>
> I am removing the sound driver (shipped with kernel 2.6.13) and then
> inserting the same. This all I am doing inside an infinite loop. Before
this
> I have reserved and used (setting the same with memset) some 900 pages to
> simulate an application environment. I am running this application on
Linux
> 2.6.13 on an ARM based target. During the course of the run I get the
> following page allocation error:
> --------------------------------------------------------------------------
--
> ---------------------------------------------------------------insmod:
page
> allocation failure. order:5, mode:0xd0
Order 5 allocations will never work reliably, except possibly at boot.
We don't have 32 contig pages to give you - fragmentation.
M.
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Page Allocation Failure, Why?? Bug in kernel??
2006-06-02 6:26 ` Abu M. Muttalib
@ 2006-06-02 7:05 ` Jesper Juhl
2006-06-02 7:21 ` Abu M. Muttalib
0 siblings, 1 reply; 11+ messages in thread
From: Jesper Juhl @ 2006-06-02 7:05 UTC (permalink / raw)
To: Abu M. Muttalib; +Cc: Martin J. Bligh, Paulo Marques, linux-kernel
On 02/06/06, Abu M. Muttalib <abum@aftek.com> wrote:
> Hi,
>
> That's precisely I want to say. The PAGES are available but they are not
> allocated to process. Why??
>
There may be 32 pages available in total, but not 32 contiguous ones -
that's a *lot* of contiguous pages to ask for in kernel space - 128KB
(assuming a 4096 byte page size).
--
Jesper Juhl <jesper.juhl@gmail.com>
Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please http://www.expita.com/nomime.html
^ permalink raw reply [flat|nested] 11+ messages in thread
* RE: Page Allocation Failure, Why?? Bug in kernel??
2006-06-02 7:05 ` Jesper Juhl
@ 2006-06-02 7:21 ` Abu M. Muttalib
2006-06-02 7:39 ` Dave Airlie
2006-06-02 7:43 ` Nick Piggin
0 siblings, 2 replies; 11+ messages in thread
From: Abu M. Muttalib @ 2006-06-02 7:21 UTC (permalink / raw)
To: Jesper Juhl; +Cc: Martin J. Bligh, Paulo Marques, linux-kernel
Hi,
I repeat my question, the required no of pages are available, as shown in
the dump produced by kernel, the request is not fulfilled. Its as follows:
DMA: 106*4kB 11*8kB 5*16kB 3*32kB 2*64kB 1*128kB 0*256kB 0*512kB 0*1024kB =
944kB
Why this is so??
~Abu.
-----Original Message-----
From: Jesper Juhl [mailto:jesper.juhl@gmail.com]
Sent: Friday, June 02, 2006 12:36 PM
To: Abu M. Muttalib
Cc: Martin J. Bligh; Paulo Marques; linux-kernel@vger.kernel.org
Subject: Re: Page Allocation Failure, Why?? Bug in kernel??
On 02/06/06, Abu M. Muttalib <abum@aftek.com> wrote:
> Hi,
>
> That's precisely I want to say. The PAGES are available but they are not
> allocated to process. Why??
>
There may be 32 pages available in total, but not 32 contiguous ones -
that's a *lot* of contiguous pages to ask for in kernel space - 128KB
(assuming a 4096 byte page size).
--
Jesper Juhl <jesper.juhl@gmail.com>
Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please http://www.expita.com/nomime.html
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Page Allocation Failure, Why?? Bug in kernel??
2006-06-02 7:21 ` Abu M. Muttalib
@ 2006-06-02 7:39 ` Dave Airlie
2006-06-02 7:43 ` Nick Piggin
1 sibling, 0 replies; 11+ messages in thread
From: Dave Airlie @ 2006-06-02 7:39 UTC (permalink / raw)
To: Abu M. Muttalib; +Cc: Jesper Juhl, Martin J. Bligh, Paulo Marques, linux-kernel
Fragmentation.
you have 32-pages scattered around the place, they are not in the one
place, you are asking for 32-contiguous pages, you cannot get this as
the memory is fragmented.
you should really never try allocating that many contiguous pages.
Dave.
On 6/2/06, Abu M. Muttalib <abum@aftek.com> wrote:
> Hi,
>
> I repeat my question, the required no of pages are available, as shown in
> the dump produced by kernel, the request is not fulfilled. Its as follows:
>
> DMA: 106*4kB 11*8kB 5*16kB 3*32kB 2*64kB 1*128kB 0*256kB 0*512kB 0*1024kB =
> 944kB
>
> Why this is so??
>
> ~Abu.
>
> -----Original Message-----
> From: Jesper Juhl [mailto:jesper.juhl@gmail.com]
> Sent: Friday, June 02, 2006 12:36 PM
> To: Abu M. Muttalib
> Cc: Martin J. Bligh; Paulo Marques; linux-kernel@vger.kernel.org
> Subject: Re: Page Allocation Failure, Why?? Bug in kernel??
>
>
> On 02/06/06, Abu M. Muttalib <abum@aftek.com> wrote:
> > Hi,
> >
> > That's precisely I want to say. The PAGES are available but they are not
> > allocated to process. Why??
> >
> There may be 32 pages available in total, but not 32 contiguous ones -
> that's a *lot* of contiguous pages to ask for in kernel space - 128KB
> (assuming a 4096 byte page size).
>
> --
> Jesper Juhl <jesper.juhl@gmail.com>
> Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html
> Plain text mails only, please http://www.expita.com/nomime.html
>
> -
> 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/
>
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Page Allocation Failure, Why?? Bug in kernel??
2006-06-02 7:21 ` Abu M. Muttalib
2006-06-02 7:39 ` Dave Airlie
@ 2006-06-02 7:43 ` Nick Piggin
2006-06-02 7:53 ` Jesper Juhl
1 sibling, 1 reply; 11+ messages in thread
From: Nick Piggin @ 2006-06-02 7:43 UTC (permalink / raw)
To: Abu M. Muttalib; +Cc: Jesper Juhl, Martin J. Bligh, Paulo Marques, linux-kernel
Abu M. Muttalib wrote:
> Hi,
>
> I repeat my question, the required no of pages are available, as shown in
> the dump produced by kernel, the request is not fulfilled. Its as follows:
>
> DMA: 106*4kB 11*8kB 5*16kB 3*32kB 2*64kB 1*128kB 0*256kB 0*512kB 0*1024kB =
> 944kB
>
> Why this is so??
Because some are kept in "emergency pools" for allocators that cannot
sleep trying to free up memory.
Teach the sound driver to use smaller buffers or just insert it at boot
and leave it inserted. Why are you removing it then reinserting it?
--
SUSE Labs, Novell Inc.
Send instant messages to your online friends http://au.messenger.yahoo.com
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Page Allocation Failure, Why?? Bug in kernel??
2006-06-02 7:43 ` Nick Piggin
@ 2006-06-02 7:53 ` Jesper Juhl
2006-06-02 8:41 ` Abu M. Muttalib
0 siblings, 1 reply; 11+ messages in thread
From: Jesper Juhl @ 2006-06-02 7:53 UTC (permalink / raw)
To: Nick Piggin; +Cc: Abu M. Muttalib, Martin J. Bligh, Paulo Marques, linux-kernel
On 02/06/06, Nick Piggin <nickpiggin@yahoo.com.au> wrote:
> Abu M. Muttalib wrote:
> > Hi,
> >
> > I repeat my question, the required no of pages are available, as shown in
> > the dump produced by kernel, the request is not fulfilled. Its as follows:
> >
> > DMA: 106*4kB 11*8kB 5*16kB 3*32kB 2*64kB 1*128kB 0*256kB 0*512kB 0*1024kB =
> > 944kB
> >
> > Why this is so??
>
> Because some are kept in "emergency pools" for allocators that cannot
> sleep trying to free up memory.
>
> Teach the sound driver to use smaller buffers or just insert it at boot
> and leave it inserted. Why are you removing it then reinserting it?
>
Or, if the driver just need 32 pages that *appear* to be contiguous
without actually having to be physically contiguous, then allocate the
space with vmalloc(). Not always possible ofcourse, but if it is for
Abu's use, then perhaps that could be a solution.
--
Jesper Juhl <jesper.juhl@gmail.com>
Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please http://www.expita.com/nomime.html
^ permalink raw reply [flat|nested] 11+ messages in thread
* RE: Page Allocation Failure, Why?? Bug in kernel??
2006-06-02 7:53 ` Jesper Juhl
@ 2006-06-02 8:41 ` Abu M. Muttalib
0 siblings, 0 replies; 11+ messages in thread
From: Abu M. Muttalib @ 2006-06-02 8:41 UTC (permalink / raw)
To: Jesper Juhl, Nick Piggin; +Cc: Martin J. Bligh, Paulo Marques, linux-kernel
Hi,
Thanks for the responses.
But it seems I am not able to convey my problem statement correctly. My
question is when 128 (((order=5)=32)*4kbytes) contiguous pages are free, as
indicated by
.....
DMA: 106*4kB 11*8kB 5*16kB 3*32kB 2*64kB .....1*128kB..... 0*256kB 0*512kB
0*1024kB = 944kB
.....
WHY IT HAS NOT BEEN ALLOCATED TO THE APPLICATION IN FIRST PLACE.
I am also facing a somwhat similar problem. I get an OOM-KILLER for a
request of 1 page, where as the output generated by OOM-KILLER shows the
following:
.....
DMA: 0*4kB 0*8kB 0*16kB 0*32kB 2*64kB 1*128kB 1*256kB 0*512kB 0*1024kB =
512kB
.....
Is it because the min_free_kbytes in /proc/sys/vm/min_free_kbytes is
configured to be 512? I tried to run the application by setting
/proc/sys/vm/min_free_kbytes to 256, but to no avail. I still got the
OOM-KILLER. Any help to aleviate the problem will be higly appreciated.
Thanks and anticipation,
~Abu.
-----Original Message-----
From: Jesper Juhl [mailto:jesper.juhl@gmail.com]
Sent: Friday, June 02, 2006 1:24 PM
To: Nick Piggin
Cc: Abu M. Muttalib; Martin J. Bligh; Paulo Marques;
linux-kernel@vger.kernel.org
Subject: Re: Page Allocation Failure, Why?? Bug in kernel??
On 02/06/06, Nick Piggin <nickpiggin@yahoo.com.au> wrote:
> Abu M. Muttalib wrote:
> > Hi,
> >
> > I repeat my question, the required no of pages are available, as shown
in
> > the dump produced by kernel, the request is not fulfilled. Its as
follows:
> >
> > DMA: 106*4kB 11*8kB 5*16kB 3*32kB 2*64kB 1*128kB 0*256kB 0*512kB
0*1024kB =
> > 944kB
> >
> > Why this is so??
>
> Because some are kept in "emergency pools" for allocators that cannot
> sleep trying to free up memory.
>
> Teach the sound driver to use smaller buffers or just insert it at boot
> and leave it inserted. Why are you removing it then reinserting it?
>
Or, if the driver just need 32 pages that *appear* to be contiguous
without actually having to be physically contiguous, then allocate the
space with vmalloc(). Not always possible ofcourse, but if it is for
Abu's use, then perhaps that could be a solution.
--
Jesper Juhl <jesper.juhl@gmail.com>
Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please http://www.expita.com/nomime.html
^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2006-06-02 8:34 UTC | newest]
Thread overview: 11+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2006-06-01 9:26 Page Allocation Failure, Why?? Bug in kernel?? Abu M. Muttalib
2006-06-01 13:25 ` Paulo Marques
2006-06-01 13:51 ` Abu M. Muttalib
2006-06-01 14:59 ` Martin J. Bligh
2006-06-02 6:26 ` Abu M. Muttalib
2006-06-02 7:05 ` Jesper Juhl
2006-06-02 7:21 ` Abu M. Muttalib
2006-06-02 7:39 ` Dave Airlie
2006-06-02 7:43 ` Nick Piggin
2006-06-02 7:53 ` Jesper Juhl
2006-06-02 8:41 ` Abu M. Muttalib
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox