lkml.org 
[lkml]   [2001]   [May]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectSwap space deallocation speed. (fwd)
Please excuse my resending this request for help. I'd first sent it to the old
address for the kernel mailing list (@vger.rutgers.edu). I then tried bouncing
that message to the right address, but that, too, had its problems. I believe
I'm finally doing it correctly.
---------- Forwarded message ----------
Date: Wed, 2 May 2001 23:15:35 -0400 (EDT)
From: Dave Mielke <dave@mielke.cc>
To: "Linux Kernel (mailing list)" <linux-kernel@vger.rutgers.edu>
Subject: Swap space deallocation speed.

Ever since I've upgraded to the 2.2.17-14 i386 kernel as provided by RedHat,
I've had several hard crashes. One allowed "/var/log/messages" to be synced, so
I was able to capture those details (which are attached to this message as the
file "crash.log"). Once, instead of crashing, the system stayed up but all of
the respawn processes in "/etc/inittab" began to respawn to rapidly, I couldn't
create a shell process to poke around, and the keyboard eventually became
unresponsive. The relevant line in the log, as you can find in the attached
"crash.log" file, appears to be:

Unable to handle kernel paging request at virtual address 00020024

My guess is that, for whatever reason, I may now be running out of swap space
fairly often. If this is true, then either my children have altered their usage
habits around the same time that I upgraded the kernel, or something about swap
space management has changed between the 2.2.16-3 and 2.2.17-14 kernels. To
this end, I've asked my children to be careful about not opening too many
windows at the same time, and the system now stays up longer but still, on
occasion, without requesting my permission, still goes down hard.

I've also been watching the amount of available swap space with the "free"
command. It predictably goes down quite quickly when a hog like netscape is
started, but, when that same application exits, the available swap space goes
back up very slowly. This would seem to make it very easy to inadvertently run
out of swap space, i.e. quitting and restarting an application still, without
the user realizing it, appears to be a bad thing to do because of the as yet
unreclaimed swap space which is still being counted.

Do any of you have any ideas? If I'm right about the slow reclamation of the
swap space, is there anything I can do, e.g. alter something in "/proc", to
speed up swap space reclamation?

Thanks.

--
Dave Mielke | 2213 Fox Crescent | I believe that the Bible is the
Phone: 1-613-726-0014 | Ottawa, Ontario | Word of God. Please contact me
EMail: dave@mielke.cc | Canada K2A 1H7 | if you're concerned about Hell.
Apr 16 11:23:06 dave kernel: Unable to handle kernel paging request at virtual address 00020024
Apr 16 11:23:06 dave kernel: current->tss.cr3 = 00101000, %%cr3 = 00101000
Apr 16 11:23:06 dave kernel: *pde = 00000000
Apr 16 11:23:06 dave kernel: Oops: 0000
Apr 16 11:23:06 dave kernel: CPU: 0
Apr 16 11:23:06 dave kernel: EIP: 0010:[locks_remove_posix+43/140]
Apr 16 11:23:06 dave kernel: EFLAGS: 00010206
Apr 16 11:23:06 dave kernel: eax: c3e6a6d0 ebx: c03e5c70 ecx: c3e6a660 edx: c03e5c70
Apr 16 11:23:06 dave kernel: esi: 00020000 edi: c14ff5d0 ebp: c3e6a6d0 esp: c142ff30
Apr 16 11:23:06 dave kernel: ds: 0018 es: 0018 ss: 0018
Apr 16 11:23:06 dave kernel: Process ppp-watch (pid: 7528, process nr: 81, stackpage=c142f000)
Apr 16 11:23:06 dave kernel: Stack: c14ff5d0 00000001 c3e6a6d0 c3e6a660 00000001 c011c9a1 00000019 00000032
Apr 16 11:23:06 dave kernel: c011ca40 00000000 bfffc000 c15147c0 00000286 c15147c0 00001d00 0000001d
Apr 16 11:23:06 dave kernel: bffffd68 c151483c 00001d00 c012768a c03e5c70 c203a280 00100047 00000001
Apr 16 11:23:06 dave kernel: Call Trace: [check_pgt_cache+17/24] [clear_page_tables+152/160] [filp_close+70/88] [do_exit+293/624] [sys_exit+14/16] [system_call+52/56]
Apr 16 11:23:06 dave kernel: Code: f6 46 24 01 74 49 8b 4c 24 5c 39 4e 14 75 40 8b 4c 24 58 8b
\
 
 \ /
  Last update: 2005-03-22 12:52    [W:0.031 / U:0.248 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site