Preemption patch problem

[Björn Östby]

OK! Thanks for the info. 
I've implemented the gfp_debug and fiddled around a bit. Memory
problems is not my specialty and the only new info attached to the error message is:

"This architecture does not implement dump_stack()"

...Which seems fair for a ppc.

I have however carefully studied the memfree value in /proc/meminfo and
by every instance I execute of "cat /proc/meminfo" it decreases by 8K.
Since I had ruthless much time this morning, I actually manually depleted the whole 32 MB with this call.. When there's about 500kb left, suddenly 200kb
is given back, but if I do multiple "cat":s real fast, memfree goes below 500kb and the kernel just starts killing processes.

Anyway, im not that keen on start hacking the kernel to get this patch 
going. I had put my hope to some strange kernel-config option which I might
had missed. If anyone knows of this, please let me know.


Best regards,
Bjorn Ostby





-----Original Message-----
From: Roger Larsson [mailto:roger.larsson at norran.net] 
Sent: den 21 april 2005 22:30
To: linuxppc-embedded at ozlabs.org
Subject: Re: Preemption patch problem


On Thursday 21 April 2005 12.08, Björn Östby wrote:
> Greetings.
>
> I have been struggling with the famous preemption patch (from Robert 
> Love) the past few days. Im using mpc823e and tried with kernels 
> 2.4.{18,21,22,23}. The patch applies flawless and so on, but when the 
> kernel is up and running strange memory problems start to appear like:
>
> _alloc_pages: 0-order allocation failed (gfp=0x1d2/0)

[
   #define __GFP_DMA       0x01
* #define __GFP_HIGHMEM   0x02
* #define __GFP_WAIT      0x10    /* Can wait and reschedule? */
   #define __GFP_HIGH      0x20    /* Should access emergency pools? */
* #define __GFP_IO        0x40    /* Can start low memory physical IO? */
* #define __GFP_HIGHIO    0x80    /* Can start high mem physical IO? */
* #define __GFP_FS        0x100   /* Can call down to low-level FS? */

- - -
#define GFP_HIGHUSER    (             __GFP_WAIT | __GFP_IO | __GFP_HIGHIO | 
__GFP_FS | __GFP_HIGHMEM)
- - -
]

So page_alloc is called with GFP_HIGHUSER, from where and why?

Try to find out what is causing this, set the 'vm_gfp_debug' see 'linux/mm/page_alloc.c'

>
> Right, so... It seems like a giant memory leak of some sort, cause 
> when I run programs the kernel goes ballistic and starts reaping 
> processes:
>
> "VM: Killing process <name>"

Well the problem is that it actually is not getting any memory. It might be code that retries to allocate memory when there really are none (you probably do not use swap)

>
> Eventually it comes down to "VM: killing init" and then it's curtains.
>
> I know that these problems is caused by the patch since the kernel 
> runs smooth without the patch applied. Does anyone have a clue what to 
> do here (beside let go of the patch)?

Analyze memory usage on the working non patched kernel.

/RogerL
_______________________________________________
Linuxppc-embedded mailing list
Linuxppc-embedded at ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded