Re: VM breakdown, 2.4.0 family

2001-01-27 Thread Marcelo Tosatti



On Sat, 27 Jan 2001, David Ford wrote:

> I have Marcelo's patch.  It isn't applicable because I am purposely not enabling any
> swap.  The problem is the system gets down to about 7 megs of buffers free and within
> three seconds has become functionally dead.  Zero response on any user input/output
> device save the magic key.
> 
> The system will then grind the harddrive solid for about 25-30 minutes then
> everything will go silent.
> 
> The brokenness is that the OOM code never activates.

Can you show the result of Alt+SysRq+M when the system is dead?

Thanks

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/



Re: VM breakdown, 2.4.0 family

2001-01-27 Thread Marcelo Tosatti


On Sat, 27 Jan 2001, David Ford wrote:

> Since the testN series and up through ac12, I experience total loss of
> control when memory is nearly exhausted.
> 
> I start with 256M and eat it up with programs until there is only about
> 7 megs left, no swap.  From that point all user processes stall and the
> disk begins to grind nonstop.  It will continue to grind for about 25-30
> minutes until it goes completely silent.  No processes get killed, no VM
> messages are emitted.
> 
> The only recourse is the magic key.  If I reboot before the disk goes
> silent I can cleanly kill X with sysrq-E and restart.
> 
> If I wait until it goes silent, all is lost.  I have to sysrq-SUB.
> 
> Note, I do not have ANY swap enabled for these tests.
> 


Could you try this patch and tell the result?

http://bazar.conectiva.com.br/~marcelo/patches/v2.4/2.4.1pre10/bg_page_aging.patch

Thanks

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/



Re: VM breakdown, 2.4.0 family

2001-01-27 Thread David Ford

I have Marcelo's patch.  It isn't applicable because I am purposely not enabling any
swap.  The problem is the system gets down to about 7 megs of buffers free and within
three seconds has become functionally dead.  Zero response on any user input/output
device save the magic key.

The system will then grind the harddrive solid for about 25-30 minutes then
everything will go silent.

The brokenness is that the OOM code never activates.

-d

Ed Tomlinson wrote:

> David Ford Wrote:
>
> >Since the testN series and up through ac12, I experience total loss of
> >control when memory is nearly exhausted.
> >
> >I start with 256M and eat it up with programs until there is only about
> >7 megs left, no swap.  From that point all user processes stall and the
> >disk begins to grind nonstop.  It will continue to grind for about 25-30
> >minutes until it goes completely silent.  No processes get killed, no VM
> >messages are emitted.
> >
> >The only recourse is the magic key.  If I reboot before the disk goes
> >silent I can cleanly kill X with sysrq-E and restart.
> >
> >If I wait until it goes silent, all is lost.  I have to sysrq-SUB.
>
> You might want to try:
>
> http://bazar.conectiva.com.br/~marcelo/patches/v2.4/2.4.1pre10/bg_page_aging.patch
>
> or
>
> ftp://ftp.cam.org/users/tomlins/pte_aging_limit_swaps.diff
>
> The first patch from Marcelo fixes a problem with aging the wrong pages.  The
> second patch is sort of a 'best of Marcelo' patch.  It contains the aging fix
> and adds conditional bg pte aging (if with activate fast than we age
> down...).  It also has code to trottle swapouts when under preasure - it only
> swaps out as much as we need now.
>
> I have fives days of uptime with it here (on test9 and test10).
>
> Feedback Welcome,
>
> Ed Tomlinson <[EMAIL PROTECTED]>

--
  There is a natural aristocracy among men. The grounds of this are virtue and 
talents. Thomas Jefferson
  The good thing about standards is that there are so many to choose from. Andrew S. 
Tanenbaum



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/



VM breakdown, 2.4.0 family

2001-01-27 Thread Ed Tomlinson

David Ford Wrote:

>Since the testN series and up through ac12, I experience total loss of
>control when memory is nearly exhausted.
>
>I start with 256M and eat it up with programs until there is only about
>7 megs left, no swap.  From that point all user processes stall and the
>disk begins to grind nonstop.  It will continue to grind for about 25-30
>minutes until it goes completely silent.  No processes get killed, no VM
>messages are emitted.
>
>The only recourse is the magic key.  If I reboot before the disk goes
>silent I can cleanly kill X with sysrq-E and restart.
>
>If I wait until it goes silent, all is lost.  I have to sysrq-SUB.

You might want to try:

http://bazar.conectiva.com.br/~marcelo/patches/v2.4/2.4.1pre10/bg_page_aging.patch

or

ftp://ftp.cam.org/users/tomlins/pte_aging_limit_swaps.diff

The first patch from Marcelo fixes a problem with aging the wrong pages.  The 
second patch is sort of a 'best of Marcelo' patch.  It contains the aging fix 
and adds conditional bg pte aging (if with activate fast than we age 
down...).  It also has code to trottle swapouts when under preasure - it only
swaps out as much as we need now.

I have fives days of uptime with it here (on test9 and test10).

Feedback Welcome,

Ed Tomlinson <[EMAIL PROTECTED]>





-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/



VM breakdown, 2.4.0 family

2001-01-26 Thread David Ford

Since the testN series and up through ac12, I experience total loss of
control when memory is nearly exhausted.

I start with 256M and eat it up with programs until there is only about
7 megs left, no swap.  From that point all user processes stall and the
disk begins to grind nonstop.  It will continue to grind for about 25-30
minutes until it goes completely silent.  No processes get killed, no VM
messages are emitted.

The only recourse is the magic key.  If I reboot before the disk goes
silent I can cleanly kill X with sysrq-E and restart.

If I wait until it goes silent, all is lost.  I have to sysrq-SUB.

Note, I do not have ANY swap enabled for these tests.

SysRq: Show Memory
Mem-info:
Free pages:   22124kB ( 0kB HighMem)
( Active: 3427, inactive_dirty: 521, inactive_clean: 0, free: 5531 (383
766 1149) )
282*4kB 55*8kB 5*16kB 0*32kB 0*64kB 0*128kB 0*256kB 1*512kB 0*1024kB
0*2048kB = 2160kB)
1769*4kB 795*8kB 156*16kB 56*32kB 21*64kB 1*128kB 1*256kB 1*512kB
0*1024kB 0*2048kB = 19964kB)
= 0kB)
Swap cache: add 0, delete 0, find 0/0
Free swap:0kB
65532 pages of RAM
0 pages of HIGHMEM
2113 reserved pages
3981 pages shared
0 pages swap cached
0 pages in page table cache
Buffer memory: 2780kB

Note the "= 0kB)" line in the middle?  Is printk() data missing?  how
about the mismatched ( to )?

-d

--
  There is a natural aristocracy among men. The grounds of this are virtue and 
talents. Thomas Jefferson
  The good thing about standards is that there are so many to choose from. Andrew S. 
Tanenbaum



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/