Re: scheduler went mad?

[Valdis.Kletnieks@vt.edu]

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

On Thu, 12 Apr 2001 16:12:55 BST, Alan Cox said:
> > I've seen the same scenario about 2-3 times a week.  kswapd and one or
> > more processes all CPU bound, totalling to 100%.  I've had 'esdplay' hung
> > on several occasions, and 2-3 times it's been xscreensaver (3.29) hung.
> > The 'hung' processes are consistently immune to kill -9, even as root, which
> > indicates to me that they're hung inside a kernel call or something.
> 
> Do you have > 800Mb of RAM ?

256M of RAM, 256M of swap.

Here's /proc/meminfo as I type:
[~]3 cat /proc/meminfo 
        total:    used:    free:  shared: buffers:  cached:
Mem:  260276224 246419456 13856768        0  8347648 75317248
Swap: 271392768 58589184 212803584
MemTotal:       254176 kB
MemFree:         13532 kB
MemShared:           0 kB
Buffers:          8152 kB
Cached:          73552 kB
Active:          49716 kB
Inact_dirty:     28800 kB
Inact_clean:      3188 kB
Inact_target:      212 kB
HighTotal:           0 kB
HighFree:            0 kB
LowTotal:       254176 kB
LowFree:         13532 kB
SwapTotal:      265032 kB
SwapFree:       207816 kB
[~]3 

> > would explain the high context-switch rate.  I'm not clear on how kswapd
> > can end up getting stuck and failing to free up something - unless it ends
> > up calling __alloc_pages itself indirectly and the PF_MEMALLOC bit isn't
> > enough to get it the memory it needs, causing a deadlock/loop between
> > kswapd and __alloc_pages/wakeup_kswapd().
> 
> bounce buffers for one

It's a Dell Optiplex GX110, using IDE.  Grepping for 'bounce buffer' in
the source shows most hits in the SCSI code, and nothing obviously jumping
out at me...

<just speculating> Is it possible that i810_audio.c is to blame? I'm looking
at alloc_dmabuf() in there, and it tries to grab a big chunk of memory
for a DMA buffer (starting at order-4), which probably explains my __alloc_pages
messages.  In addition, I run Enlightenment with audio enabled - so it's
quite possible that xscreensaver will generate a 'click' sound when it
pops up its dialog window - again tossing us into i810_audio. (scenario
there - mouse event happens while screen locked, xscreensaver wakes up and
starts mapping a window - E plays the sound, hosing the i810_audio driver,
and then when xscreensaver gets the CPU back, its next call for a page
gets wedged up.

Would it be worth applying Ed Tomlinson's icache/dcache patches and seeing
if that helps?


-- 
				Valdis Kletnieks
				Operating Systems Analyst
				Virginia Tech



[-- Attachment #2: Type: application/pgp-signature, Size: 211 bytes --]