summaryrefslogtreecommitdiffstats
path: root/contrib/llvm/lib/Analysis/ValueTracking.cpp
diff options
context:
space:
mode:
authorkib <kib@FreeBSD.org>2013-10-02 06:00:34 +0000
committerkib <kib@FreeBSD.org>2013-10-02 06:00:34 +0000
commit031d824a492a5e1aa9303a5ead6dd94db7dd4597 (patch)
treee9c128e476c987ae2e2cb8f65c57cdcc83d8338f /contrib/llvm/lib/Analysis/ValueTracking.cpp
parentb029856426413831b7cd0b8368427dbd646b35d2 (diff)
downloadFreeBSD-src-031d824a492a5e1aa9303a5ead6dd94db7dd4597.zip
FreeBSD-src-031d824a492a5e1aa9303a5ead6dd94db7dd4597.tar.gz
When helping the bufdaemon from the buffer allocation context, there
is no sense to walk the whole dirty buffer queue. We are only interested in, and can operate on, the buffers owned by the current vnode [1]. Instead of calling generic queue flush routine, do VOP_FSYNC() if possible. Holding the dirty buffer queue lock in the bufdaemon, without dropping it, can cause starvation of buffer writes from other threads. This is esp. easy to reproduce on the big memory machines, where large files are written, causing almost all dirty buffers accumulating in several big files, which vnodes are locked by writers. Bufdaemon cannot flush any buffer, but is iterating over the whole dirty queue continuously. Since dirty queue mutex is not dropped, bufdone() in g_up thread is starved, usually deadlocking the machine [2]. Mitigate this by dropping the queue lock after the vnode is locked, allowing other queue lock contenders to make a progress. Discussed with: Jeff [1] Reported by: pho [2] Tested by: pho Sponsored by: The FreeBSD Foundation MFC after: 2 weeks Approved by: re (hrs)
Diffstat (limited to 'contrib/llvm/lib/Analysis/ValueTracking.cpp')
0 files changed, 0 insertions, 0 deletions
OpenPOWER on IntegriCloud