Use KM_PUSHPAGE instead of KM_SLEEP
authorBrian Behlendorf <behlendorf1@llnl.gov>
Sat, 19 Mar 2011 21:34:30 +0000 (14:34 -0700)
committerBrian Behlendorf <behlendorf1@llnl.gov>
Tue, 22 Mar 2011 19:14:55 +0000 (12:14 -0700)
commit691f6ac4c2858d64afc2a0dc1bd2b8c041d68502
tree97cd5916e20c2f6dbc535246c86a4947f1aeabb8
parentf47c42e2143ccf83bb5ddca4251c9db14859a0b5
Use KM_PUSHPAGE instead of KM_SLEEP

It used to be the case that all KM_SLEEP allocations were GFS_NOFS.
Unfortunately this often resulted in the kernel being unable to
reclaim the ARC, inode, and dentry caches in a timely manor.
The fix was to make KM_SLEEP a GFP_KERNEL allocation in the SPL.

However, this increases the posibility of deadlocking the system
on a zfs write thread.  If a zfs write thread attempts to perform
an allocation it may trigger synchronous reclaim.  This reclaim
may attempt to flush dirty data/inode to disk to free memory.
Unforunately, this write cannot finish because the write thread
which would handle it is holding the previous transaction open.
Deadlock.

To avoid this all allocations in the zfs write thread path must
use KM_PUSHPAGE which prohibits synchronous reclaim for that
thread.  In this way forward progress in ensured.  The risk
with this change is I missed updating an allocation for the
write threads leaving an increased posibility of deadlock.  If
any deadlocks remain they will be unlikely but we'll have to
make sure they all get fixed.
module/zfs/arc.c
module/zfs/zfs_znode.c
module/zfs/zio.c