: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.

:I have tweaked swap_pager.c as you suggested earlier. It runs :about an order of magnitude slower under load now, since it's :doing a vm_object_pip_wait() on every swap-backed object in the :system that's currently paging, even for objects that are paging :to a different swap device. Unless you have a better idea, I :think one way to improve performance might be to skip the busy :objects, and after the whole hash has been scanned, rescan :starting at the first index that was skipped. Of course, it would :have to wait for at least one object on each iteration so it :doesn't get into a tight loop.

This sounds reasonable, it's certainly worth a shot. Another thing you may be able to do is to try to cluster the pageins on an object-by-object basis since our swap-scanning is probably resulting in having to wait for the PIP count of the same object many times (for large objects with lots of swap blocks).

Hmm. Since we have to track down every swap block and we can (do?) get a count of pages that need to be swapped in, we could remove the PIP wait code and simply loop on the swap hash table over and over again until we've found all the swap blocks that we know have been allocated to that device. Or something like that.

:Another important optimization is to page in the entire block at :once, rather than doing it a page at a time. I tried to do this :with the following algorithm: : : - grab SWAP_META_PAGES pages : - note which ones are already in core using a bitmap : - call getpages() to retrieve the entire range :... : :This didn't work, and it produced all sorts of interesting panics :for reasons I haven't yet figured out. My latest patch has some :remnants of of some my attempts in swp_pager_force_pagein(), but :I'll probably leave that optimization for another day unless you :can see an obvious flaw in my approach.

I can probably deal with that post-commit. Lets ignore it for now. The main goal at the moment should be robustness.

:BTW, thanks for all of your help!

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