'swap_pager: indefinite wait buffer' with swapfile
Matthew Dillon
dillon at apollo.backplane.com
Tue Sep 13 15:00:42 PDT 2005
:
:
:--bp/iNruPH9dso1Pn
:Content-Type: text/plain; charset=us-ascii
:Content-Disposition: inline
:
:I configured a vnode-backed md and enabled swapping on it. A few
:hours later after moderate swap use the console showed:
:
:swap_pager: indefinite wait buffer: bufobj: 0, blkno: 889347, size: 8192
:[...repeated...]
:
:The backing store was a sparse file, but there was ample space:
This is likely your problem. Do NOT use a sparse file for file-backed
swap.
If you carefully backtrace the other processes on the stuck system I'll
bet you will find one stuck in ffs_balloc (or similar) in addition to
the one you found stuck in allocbuf().
If you do, then its the same bug I reported to Kirk not too long ago.
I determined that there was a lock order reveral between the locking
of indirect blocks (on files) and related data blocks. It turns out
that the data block must always be locked first because the standard
BMAP path holds a locked data block while resolving the indirect block.
However, when a dirty VM page is written to sparse file backing store
the indirect block winds up being locked before the data block. It's
only a problem when a VM fault has to allocate the underlying filesystem
block (in our case, rtorrent was read()ing directly into a memory mapped
sparse file).
In anycase, the fix for FFS is /usr/src/sys/vfs/ufs/ffs_balloc.c:1.12
in the DragonFly source tree.
I believe that may fix your swap issue as well, but my first comment
still stands: Do NOT ever use a sparse file for swap backing store.
Massive fragmentation within the file will occur and if the machine swaps
regularly then after a while it will no longer be able to optimize
swap I/O and will be even MORE sludgy then the normal sludginess you
get when you have to page to swap.
-Matt
Matthew Dillon
<dillon at backplane.com>
More information about the freebsd-current
mailing list