atom feed30 messages in org.freebsd.freebsd-hackersRe: swapoff?
FromSent OnAttachments
Sean KellyJul 12, 2002 9:02 pm 
David SchultzJul 12, 2002 10:23 pm 
David SchultzJul 12, 2002 10:32 pm 
Matthew DillonJul 12, 2002 11:51 pm 
David SchultzJul 13, 2002 12:18 am 
Matthew DillonJul 13, 2002 12:27 am 
Peter WemmJul 13, 2002 12:33 am 
Andrey AlekseyevJul 13, 2002 1:23 am 
Terry LambertJul 13, 2002 3:17 am 
Jon MiniJul 13, 2002 3:44 am 
Terry LambertJul 13, 2002 4:30 am 
David SchultzJul 13, 2002 4:57 am 
Terry LambertJul 13, 2002 5:22 am 
Matthew DillonJul 13, 2002 9:36 am 
David SchultzJul 13, 2002 2:00 pm 
Peter WemmJul 13, 2002 3:39 pm 
David SchultzOct 7, 2002 8:38 am 
Matthew DillonOct 7, 2002 4:46 pm 
Nate LawsonOct 7, 2002 9:47 pm 
David SchultzOct 8, 2002 4:35 am 
David SchultzOct 8, 2002 4:39 am 
Matthew DillonOct 8, 2002 10:04 am 
Matthew DillonOct 8, 2002 10:45 am 
David SchultzOct 11, 2002 6:01 am 
Matthew DillonOct 11, 2002 11:14 am 
David SchultzOct 14, 2002 2:41 am 
Matthew DillonOct 14, 2002 8:55 am 
David SchultzOct 15, 2002 12:10 am 
David SchultzOct 23, 2002 11:07 am 
Matthew DillonOct 23, 2002 11:45 am 
Subject:Re: swapoff?
From:David Schultz (dsch@uclink.Berkeley.EDU)
Date:Oct 23, 2002 11:07:55 am
List:org.freebsd.freebsd-hackers

Thus spake Matthew Dillon <dil@apollo.backplane.com>:

:The concern was that there could be a race where the process is :swapped out again after I have swapped it back in but before I can :dirty its pages. (Perhaps I need to hold the process lock a bit :longer.) Under heavy swapping load, swapoff() is failing to find :a single page about one time out of ten, and I thought that might :be the cause.

Have you definitively tracked down the missing page? It ought to be fairly easy to do from a kernel core with a gdb macro.

No, I've tested it extensively, and I haven't been able to reproduce the problem since I updated my sources. (It was hard to reproduce beforehand.) I did two more runs with one swap device and two runs with two swap devices, and it worked even when the system was thrashing.

The latest patches are at

http://www.CSUA.Berkeley.EDU/~das/swapoff.patch4

Performance is now much better when there are multiple swap devices. Instead of effectively having to wait for each hash chain to become quiescent, swapoff now skips busy objects, then does a complete rescan if it missed anything. Only a few rescans are required, even with multiple active swap devices. A clustering optimization might still be worthwhile, but that can be done another day.

(Sorry for the delay in getting back to you. I've been too busy and sick for the last week to work on this.)

To Unsubscribe: send mail to majo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message