<feed xmlns='http://www.w3.org/2005/Atom'>
<title>xavi/android_kernel_m2note/drivers/md/dm-bufio.c, branch ng-7.1.2</title>
<subtitle>Unnamed repository; edit this file 'description' to name the repository.
</subtitle>
<id>https://gitea.privatedns.org/xavi/android_kernel_m2note/atom?h=ng-7.1.2</id>
<link rel='self' href='https://gitea.privatedns.org/xavi/android_kernel_m2note/atom?h=ng-7.1.2'/>
<link rel='alternate' type='text/html' href='https://gitea.privatedns.org/xavi/android_kernel_m2note/'/>
<updated>2017-12-10T13:25:12+00:00</updated>
<entry>
<title>BACKPORT: dm bufio: don't take the lock in dm_bufio_shrink_count</title>
<updated>2017-12-10T13:25:12+00:00</updated>
<author>
<name>Mikulas Patocka</name>
<email>mpatocka@redhat.com</email>
</author>
<published>2016-11-23T21:52:01+00:00</published>
<link rel='alternate' type='text/html' href='https://gitea.privatedns.org/xavi/android_kernel_m2note/commit/?id=d3dc597a6c754da47500866c8ebaa46bda2b5e1d'/>
<id>urn:sha1:d3dc597a6c754da47500866c8ebaa46bda2b5e1d</id>
<content type='text'>
dm_bufio_shrink_count() is called from do_shrink_slab to find out how many
freeable objects are there. The reported value doesn't have to be precise,
so we don't need to take the dm-bufio lock.

Suggested-by: David Rientjes &lt;rientjes@google.com&gt;
Signed-off-by: Mikulas Patocka &lt;mpatocka@redhat.com&gt;
Signed-off-by: Mike Snitzer &lt;snitzer@redhat.com&gt;

Bug: 64122284
Change-Id: Id2c3446e03e865f424be8666b1ee0822b9e33a63
(cherry picked from commit d12067f428c037b4575aaeb2be00847fc214c24a)
Signed-off-by: Sami Tolvanen &lt;samitolvanen@google.com&gt;
Signed-off-by: Francisco Franco &lt;franciscofranco.1990@gmail.com&gt;
</content>
</entry>
<entry>
<title>BACKPORT: dm bufio: avoid sleeping while holding the dm_bufio lock</title>
<updated>2017-12-10T13:24:54+00:00</updated>
<author>
<name>Douglas Anderson</name>
<email>dianders@chromium.org</email>
</author>
<published>2016-11-17T19:24:20+00:00</published>
<link rel='alternate' type='text/html' href='https://gitea.privatedns.org/xavi/android_kernel_m2note/commit/?id=2b9cec0604125ebb95b7095fdba876b01eef841c'/>
<id>urn:sha1:2b9cec0604125ebb95b7095fdba876b01eef841c</id>
<content type='text'>
We've seen in-field reports showing _lots_ (18 in one case, 41 in
another) of tasks all sitting there blocked on:

  mutex_lock+0x4c/0x68
  dm_bufio_shrink_count+0x38/0x78
  shrink_slab.part.54.constprop.65+0x100/0x464
  shrink_zone+0xa8/0x198

In the two cases analyzed, we see one task that looks like this:

  Workqueue: kverityd verity_prefetch_io

  __switch_to+0x9c/0xa8
  __schedule+0x440/0x6d8
  schedule+0x94/0xb4
  schedule_timeout+0x204/0x27c
  schedule_timeout_uninterruptible+0x44/0x50
  wait_iff_congested+0x9c/0x1f0
  shrink_inactive_list+0x3a0/0x4cc
  shrink_lruvec+0x418/0x5cc
  shrink_zone+0x88/0x198
  try_to_free_pages+0x51c/0x588
  __alloc_pages_nodemask+0x648/0xa88
  __get_free_pages+0x34/0x7c
  alloc_buffer+0xa4/0x144
  __bufio_new+0x84/0x278
  dm_bufio_prefetch+0x9c/0x154
  verity_prefetch_io+0xe8/0x10c
  process_one_work+0x240/0x424
  worker_thread+0x2fc/0x424
  kthread+0x10c/0x114

...and that looks to be the one holding the mutex.

The problem has been reproduced on fairly easily:
0. Be running Chrome OS w/ verity enabled on the root filesystem
1. Pick test patch: http://crosreview.com/412360
2. Install launchBalloons.sh and balloon.arm from
     http://crbug.com/468342
   ...that's just a memory stress test app.
3. On a 4GB rk3399 machine, run
     nice ./launchBalloons.sh 4 900 100000
   ...that tries to eat 4 * 900 MB of memory and keep accessing.
4. Login to the Chrome web browser and restore many tabs

With that, I've seen printouts like:
  DOUG: long bufio 90758 ms
...and stack trace always show's we're in dm_bufio_prefetch().

The problem is that we try to allocate memory with GFP_NOIO while
we're holding the dm_bufio lock.  Instead we should be using
GFP_NOWAIT.  Using GFP_NOIO can cause us to sleep while holding the
lock and that causes the above problems.

The current behavior explained by David Rientjes:

  It will still try reclaim initially because __GFP_WAIT (or
  __GFP_KSWAPD_RECLAIM) is set by GFP_NOIO.  This is the cause of
  contention on dm_bufio_lock() that the thread holds.  You want to
  pass GFP_NOWAIT instead of GFP_NOIO to alloc_buffer() when holding a
  mutex that can be contended by a concurrent slab shrinker (if
  count_objects didn't use a trylock, this pattern would trivially
  deadlock).

This change significantly increases responsiveness of the system while
in this state.  It makes a real difference because it unblocks kswapd.
In the bug report analyzed, kswapd was hung:

   kswapd0         D ffffffc000204fd8     0    72      2 0x00000000
   Call trace:
   [&lt;ffffffc000204fd8&gt;] __switch_to+0x9c/0xa8
   [&lt;ffffffc00090b794&gt;] __schedule+0x440/0x6d8
   [&lt;ffffffc00090bac0&gt;] schedule+0x94/0xb4
   [&lt;ffffffc00090be44&gt;] schedule_preempt_disabled+0x28/0x44
   [&lt;ffffffc00090d900&gt;] __mutex_lock_slowpath+0x120/0x1ac
   [&lt;ffffffc00090d9d8&gt;] mutex_lock+0x4c/0x68
   [&lt;ffffffc000708e7c&gt;] dm_bufio_shrink_count+0x38/0x78
   [&lt;ffffffc00030b268&gt;] shrink_slab.part.54.constprop.65+0x100/0x464
   [&lt;ffffffc00030dbd8&gt;] shrink_zone+0xa8/0x198
   [&lt;ffffffc00030e578&gt;] balance_pgdat+0x328/0x508
   [&lt;ffffffc00030eb7c&gt;] kswapd+0x424/0x51c
   [&lt;ffffffc00023f06c&gt;] kthread+0x10c/0x114
   [&lt;ffffffc000203dd0&gt;] ret_from_fork+0x10/0x40

By unblocking kswapd memory pressure should be reduced.

Suggested-by: David Rientjes &lt;rientjes@google.com&gt;
Reviewed-by: Guenter Roeck &lt;linux@roeck-us.net&gt;
Signed-off-by: Douglas Anderson &lt;dianders@chromium.org&gt;
Signed-off-by: Mike Snitzer &lt;snitzer@redhat.com&gt;

Bug: 64122284
Change-Id: I1ce9367c921d7ab07ca9e3d403c95cd0d333915c
(cherry picked from commit 9ea61cac0b1ad0c09022f39fd97e9b99a2cfc2dc)
Signed-off-by: Sami Tolvanen &lt;samitolvanen@google.com&gt;
Signed-off-by: Francisco Franco &lt;franciscofranco.1990@gmail.com&gt;
</content>
</entry>
<entry>
<title>first commit</title>
<updated>2016-08-15T02:19:42+00:00</updated>
<author>
<name>Meizu OpenSource</name>
<email>patchwork@meizu.com</email>
</author>
<published>2016-08-15T02:19:42+00:00</published>
<link rel='alternate' type='text/html' href='https://gitea.privatedns.org/xavi/android_kernel_m2note/commit/?id=d2e1446d81725c351dc73a03b397ce043fb18452'/>
<id>urn:sha1:d2e1446d81725c351dc73a03b397ce043fb18452</id>
<content type='text'>
</content>
</entry>
</feed>
