2.4.0-t9p7 and mmap002 - freeze

Hi,

Tried latest patch with the same result - freeze...

No extra patches added.

running from console as root
mmap002 from memtest-0.0.3
with RAMSIZE defined as 90 MB (I have 96MB)
after a while with heavy disk access (thrashing?) the drive becomes silent - no more progress...
[if you can not repeat this - try with less memory 32 MB...]

Magic works!

Magic memory
Constantly LOW on inactive_clean (0 is the most common) lots of shared memory (almost equals active) [can be normal condition since mmap002 produces dirty
mmaped pages]

Magic process:
Manual samples gave the following locations. (NOTE: not a call trace)
We are trying to clean pages, but do we make any progress since disk is silent?

Trace; c0127d85 <page_launder+3d/724>
Trace; c0126dad <deactivate_page_nolock+13d/248>
Trace; c0127e00 <page_launder+b8/724>
Trace; c0128035 <page_launder+2ed/724>
Trace; c0127dcc <page_launder+84/724>
Trace; c0127dd0 <page_launder+88/724>
Trace; c0127e00 <page_launder+b8/724>
Trace; c012fd38 <try_to_free_buffers+4/138>

Magic Sigterm (Alt+SysRq+E)
Gives you a running system again.

Notes:
Probably timing critical for entry into this state since adding a few printk:s makes it happen less often. I have even got complete mmap002 runs succeed - but disk is running too much and for too long time... a lot more than 10 min - normal run on previous testX did usually take less than 3 minutes.

/RogerL

--
Home page:
http://www.norran.net/nra02596/
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux.eu.org/Linux-MM/

Ditto.

Ditto.

I'm using a little proggy from Christoph Rohland (swptst.c), and do not have to jump through any hoops to reproduce the freeze.

If a kdb call trace will help (doubt it.. see below) I can post one.

Not here. I looked at it with an IKD kernel, and here it's the same loop as before.. __alloc_pages() running through try_again forever. inactive_clean=0, a few pages bouncing between active and inactive_dirty. __switch_to() never happens. (though I can artificially yield and thus make sysrq-e work. Artificially scheduling only ensures that all other tasks loop the same way. [coz inactive_clean=0.. page_launder() is always failing to find something freeable])

I'm still at < 1 minute survival.. with many seconds to spare ;-) I have yet to have a run succeed, though virgin source _does_ last a bit longer (odd) than KDB enabled kernel.

-Mike

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux.eu.org/Linux-MM/

I'm finally back from Linux Kongress and Linux Expo and will look at the latest tree and integrate the fixes I made while on the road later today (after I get some sleep).

I have fixed this particular bug, which was caused by us moving unfreeable pages to the inactive_dirty list and back again, while not accomplishing anything useful.

The fix for this is trivial and I'll post it later today (cleaned up and working in the current source tree).

regards,

Rik
--
"What you're running that piece of shit Gnome?!?!"
-- Miguel de Icaza, UKUUG 2000

http://www.conectiva.com/ http://www.surriel.com/

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux.eu.org/Linux-MM/

Cool!

I've had a tiny bit of success (swptst _passed_ once, and currently locks with 1 inactive_clean page instead of always 0;) by fiddling with __alloc_pages() a bit.

One thing that I _think_ may be a problem is using stale information. direct_reclaim is set once, it's set without checking that a reclaim is possible, and it's not updated as we proceed although the situation may change.

Another thing I'm curious about is increasing memory pressure in the event of an allocation failure (retry). Why do we do that?

Comments?

-Mike (down periscope.. ahead dead slow;)

P.S. in buffer.c, we do a LockPage(), but no UnlockPage() in the case of no_buffer_head.. is that correct?

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux.eu.org/Linux-MM/

We were short on free memory, so kswapd should work /harder/ to keep up with the current load.

No it isn't ;) Thanks for pointing out this one...

regards,

Rik
--
"What you're running that piece of shit Gnome?!?!"
-- Miguel de Icaza, UKUUG 2000

http://www.conectiva.com/ http://www.surriel.com/

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux.eu.org/Linux-MM/