SOLARIS: Granular multiPage detection
authorAndrew Deason <adeason@sinenomine.net>
Wed, 29 Jun 2011 18:51:22 +0000 (13:51 -0500)
committerDerrick Brashear <shadow@dementia.org>
Thu, 30 Jun 2011 14:28:05 +0000 (07:28 -0700)
commit31a001f60e5fe729b315f679d1d43b367bd74ea5
tree5987615d5ba6bb40d3c0f0c59806d900612052b6
parent8017773587bf28a58e480f634fdccc287c443d3b
SOLARIS: Granular multiPage detection

Currently, a struct vcache has a multiPage counter, indicating how
many afs_getpage requests are in-flight for that vcache that involve
retrieving multiple pages. Any dcache associated with such vcaches are
then avoided when choosing dcache entries to evict from the cache,
since we may deadlock when trying to evict a dcache entry from one of
the earlier afs_GetOnePage calls in a particular afs_getpage request.

This behavior can cause the client to become unusable if the cache
becomes full, and the only items in the cache are dcache entries in a
file that has an in-flight multi-page afs_getpage request. Since, in
that case, we cannot kick out any entries from the cache, and so we
wait forever to wait for the cache utilization to go down.

To prevent this from occurring, record exactly which ranges in the
file have in-flight multi-page afs_getpage requests, and just avoid
dcache entries in those ranges. This way afs_GetDownD can evict dcache
entries in the same file, but still avoid entries that would cause a
deadlock.

Also add some comments explaining this situation a bit more.

Change-Id: Idb305c8b7511065301739542772d16d4fe8cd574
Reviewed-on: http://gerrit.openafs.org/4896
Reviewed-by: Derrick Brashear <shadow@dementia.org>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
src/afs/SOLARIS/osi_vcache.c
src/afs/SOLARIS/osi_vm.c
src/afs/SOLARIS/osi_vnodeops.c
src/afs/afs.h
src/afs/afs_dcache.c
src/afs/afs_prototypes.h