Linux: Restrict # of cbrs we allocate at once
authorSimon Wilkinson <sxw@your-file-system.com>
Thu, 21 Apr 2011 15:07:05 +0000 (16:07 +0100)
committerDerrick Brashear <shadow@dementia.org>
Mon, 25 Apr 2011 20:39:53 +0000 (13:39 -0700)
commit3cb97cdaa867b0d9fef84c683251a0a8f59a1519
tree849e53f4da1d7e5894a3b3a2370676235daae759
parent211e906c86be9ad9cba324e776d56093579b6653
Linux: Restrict # of cbrs we allocate at once

With commit a309e274632993c5aeec04c6e090f5ac95837a40, we changed the
number of CBRs that we allocate in a chunk from 300 to 1024. However,
this change takes the amount of memory requried to allocate a chunk
of CBRs above PAGE_SIZE on Linux. This changes the allocator that we
use from kmalloc to vmalloc. Whilst we can, and do, prevent kmalloc
from flushing filesystem pages when we invoke it, we don't have a
similar level of control over vmalloc.

In one reported case, clients deadlock whilst attempting to allocate
this memory, in a call stack that looks something like:

  afs_Daemon -> afs_ShakeLooseVCaches -> osi_TryEvictVCache
      -> afs_FlushVCache -> afs_QueueVCB -> afs_AllocCBR
      -> osi_linux_alloc -> ... -> __vmalloc_node -> ...
      -> try_to_free_pages

This is probably because we end up deadlocking in the writeback
invoked by try_to_free_pages, likely due to locks which are held
by ShakeLooseVCaches.

As a quick fix for the problem, make sure that the memory we
allocate always fits within a page, so we always use kmalloc for
it.

FIXES 129751

Change-Id: I8b5be06ed62764b67f99792df66e9cb0f8941fd6
Reviewed-on: http://gerrit.openafs.org/4510
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Jeffrey Altman <jaltman@openafs.org>
Reviewed-by: Derrick Brashear <shadow@dementia.org>
src/afs/afs.h