{"push_id":2588509051,"size":1,"distinct_size":1,"ref":"refs/heads/caf/aosp-common/android-3.18","head":"7b2488b7ee9fb0c9ff51bb41881d4d77d1499bd6","before":"98b490af4147f839e701bfe79cc41f37d7bcbe72","commits":[{"sha":"7b2488b7ee9fb0c9ff51bb41881d4d77d1499bd6","author":{"name":"Douglas Anderson","email":"49983c4a76b998672954ed5edf4a62db4a336502@chromium.org"},"message":"UPSTREAM: dm bufio: avoid sleeping while holding the dm_bufio lock\n\nWe've seen in-field reports showing _lots_ (18 in one case, 41 in\nanother) of tasks all sitting there blocked on:\n\n  mutex_lock+0x4c/0x68\n  dm_bufio_shrink_count+0x38/0x78\n  shrink_slab.part.54.constprop.65+0x100/0x464\n  shrink_zone+0xa8/0x198\n\nIn the two cases analyzed, we see one task that looks like this:\n\n  Workqueue: kverityd verity_prefetch_io\n\n  __switch_to+0x9c/0xa8\n  __schedule+0x440/0x6d8\n  schedule+0x94/0xb4\n  schedule_timeout+0x204/0x27c\n  schedule_timeout_uninterruptible+0x44/0x50\n  wait_iff_congested+0x9c/0x1f0\n  shrink_inactive_list+0x3a0/0x4cc\n  shrink_lruvec+0x418/0x5cc\n  shrink_zone+0x88/0x198\n  try_to_free_pages+0x51c/0x588\n  __alloc_pages_nodemask+0x648/0xa88\n  __get_free_pages+0x34/0x7c\n  alloc_buffer+0xa4/0x144\n  __bufio_new+0x84/0x278\n  dm_bufio_prefetch+0x9c/0x154\n  verity_prefetch_io+0xe8/0x10c\n  process_one_work+0x240/0x424\n  worker_thread+0x2fc/0x424\n  kthread+0x10c/0x114\n\n...and that looks to be the one holding the mutex.\n\nThe problem has been reproduced on fairly easily:\n0. Be running Chrome OS w/ verity enabled on the root filesystem\n1. Pick test patch: http://crosreview.com/412360\n2. Install launchBalloons.sh and balloon.arm from\n     http://crbug.com/468342\n   ...that's just a memory stress test app.\n3. On a 4GB rk3399 machine, run\n     nice ./launchBalloons.sh 4 900 100000\n   ...that tries to eat 4 * 900 MB of memory and keep accessing.\n4. Login to the Chrome web browser and restore many tabs\n\nWith that, I've seen printouts like:\n  DOUG: long bufio 90758 ms\n...and stack trace always show's we're in dm_bufio_prefetch().\n\nThe problem is that we try to allocate memory with GFP_NOIO while\nwe're holding the dm_bufio lock.  Instead we should be using\nGFP_NOWAIT.  Using GFP_NOIO can cause us to sleep while holding the\nlock and that causes the above problems.\n\nThe current behavior explained by David Rientjes:\n\n  It will still try reclaim initially because __GFP_WAIT (or\n  __GFP_KSWAPD_RECLAIM) is set by GFP_NOIO.  This is the cause of\n  contention on dm_bufio_lock() that the thread holds.  You want to\n  pass GFP_NOWAIT instead of GFP_NOIO to alloc_buffer() when holding a\n  mutex that can be contended by a concurrent slab shrinker (if\n  count_objects didn't use a trylock, this pattern would trivially\n  deadlock).\n\nThis change significantly increases responsiveness of the system while\nin this state.  It makes a real difference because it unblocks kswapd.\nIn the bug report analyzed, kswapd was hung:\n\n   kswapd0         D ffffffc000204fd8     0    72      2 0x00000000\n   Call trace:\n   [<ffffffc000204fd8>] __switch_to+0x9c/0xa8\n   [<ffffffc00090b794>] __schedule+0x440/0x6d8\n   [<ffffffc00090bac0>] schedule+0x94/0xb4\n   [<ffffffc00090be44>] schedule_preempt_disabled+0x28/0x44\n   [<ffffffc00090d900>] __mutex_lock_slowpath+0x120/0x1ac\n   [<ffffffc00090d9d8>] mutex_lock+0x4c/0x68\n   [<ffffffc000708e7c>] dm_bufio_shrink_count+0x38/0x78\n   [<ffffffc00030b268>] shrink_slab.part.54.constprop.65+0x100/0x464\n   [<ffffffc00030dbd8>] shrink_zone+0xa8/0x198\n   [<ffffffc00030e578>] balance_pgdat+0x328/0x508\n   [<ffffffc00030eb7c>] kswapd+0x424/0x51c\n   [<ffffffc00023f06c>] kthread+0x10c/0x114\n   [<ffffffc000203dd0>] ret_from_fork+0x10/0x40\n\nBy unblocking kswapd memory pressure should be reduced.\n\nChange-Id: I424022893c4934af71aaf52af00f90b17bca2561\nSuggested-by: David Rientjes <rientjes@google.com>\nReviewed-by: Guenter Roeck <linux@roeck-us.net>\nSigned-off-by: Douglas Anderson <dianders@chromium.org>\nSigned-off-by: Mike Snitzer <snitzer@redhat.com>\n(cherry picked from commit 9ea61cac0b1ad0c09022f39fd97e9b99a2cfc2dc)\nSigned-off-by: Minchan Kim <minchan@google.com>","distinct":true,"url":"https://api.github.com/repos/Jackeagle/kernel_msm-3.10/commits/7b2488b7ee9fb0c9ff51bb41881d4d77d1499bd6"}]}
{"actor":{"display_login":"Jackeagle"}}