Messages in this thread | | | Subject | Re: scheduler went mad? | From | Valdis.Kletnieks@vt ... | Date | Thu, 12 Apr 2001 11:44:55 -0400 |
| |
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
[unhandled content-type:application/pgp-signature] | |