When I was poking at low memory situations over a year ago, I remember coding up the patch:

https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/471933

AKA: WIP: Speed up / improve mali shrinker code

---

I beleive I originally coded it up because when I was reproing OOMs and looking at stack crawls in kdb I saw a bunch of processes sitting in "kbase_mem_evictable_reclaim_count_objects".  

Ah, here's one such (really old) stack crawl:

Stack traceback for pid 2770
0xffffffc0ad378000     2770        2  0    4   D  0xffffffc0ad3788e0  loop1
Call trace:
[<ffffffc000205d78>] __switch_to+0xf4/0x108
[<ffffffc000c123e4>] __schedule+0x788/0xa90
[<ffffffc000c127c0>] schedule+0xd4/0x104
[<ffffffc000c12c9c>] schedule_preempt_disabled+0x34/0x5c
[<ffffffc000c150a4>] __mutex_lock_slowpath+0x164/0x26c
[<ffffffc000c151f8>] mutex_lock+0x4c/0x78
[<ffffffc00075b9cc>] kbase_mem_evictable_reclaim_count_objects+0x38/0x98
[<ffffffc000389c44>] shrink_slab.part.54+0x134/0x5c0
[<ffffffc00038d790>] shrink_zone+0xf0/0x24c
[<ffffffc00038ddd8>] try_to_free_pages+0x4ec/0x6d0
[<ffffffc00037cf80>] __alloc_pages_nodemask+0x7b8/0xbac
[<ffffffc000373244>] generic_file_read_iter+0x578/0x790
[<ffffffc0003e3c44>] vfs_iter_read+0xbc/0x118
[<ffffffc0007ba3e8>] loop_queue_work+0x7e4/0xb4c
[<ffffffc000251f6c>] kthread_worker_fn+0x1fc/0x298
[<ffffffc000251cf4>] kthread+0x164/0x178
[<ffffffc0002045d0>] ret_from_fork+0x10/0x40
Stack traceback for pid 3056
0xffffffc0aaa31c00     3056      609  0    3   D  0xffffffc0aaa324e0  bash
Call trace:
[<ffffffc000205d78>] __switch_to+0xf4/0x108
[<ffffffc000c123e4>] __schedule+0x788/0xa90
[<ffffffc000c127c0>] schedule+0xd4/0x104
[<ffffffc000c12c9c>] schedule_preempt_disabled+0x34/0x5c
[<ffffffc000c150a4>] __mutex_lock_slowpath+0x164/0x26c
[<ffffffc000c151f8>] mutex_lock+0x4c/0x78
[<ffffffc00075b9cc>] kbase_mem_evictable_reclaim_count_objects+0x38/0x98
[<ffffffc000389c44>] shrink_slab.part.54+0x134/0x5c0
[<ffffffc00038d790>] shrink_zone+0xf0/0x24c
[<ffffffc00038ddd8>] try_to_free_pages+0x4ec/0x6d0
[<ffffffc00037cf80>] __alloc_pages_nodemask+0x7b8/0xbac
[<ffffffc0003c4728>] __read_swap_cache_async+0xb0/0x2a0
[<ffffffc0003c4960>] read_swap_cache_async+0x48/0x7c
[<ffffffc0003c4b30>] swapin_readahead+0x19c/0x1cc
[<ffffffc0003aef38>] handle_mm_fault+0x10e8/0x1690
[<ffffffc00021bb10>] do_page_fault+0x1ac/0x3c4
[<ffffffc0002003bc>] do_mem_abort+0x70/0x100

---

I also remember doing some timings.  I believe I used ktime at the start and end of kbase_mem_evictable_reclaim_count_objects() and printed w/ trace_printk() when it was slower than a certain number.  I found old logs that looked like this:

           <...>-3719  [000] ....   106.622455: kbase_mem_evictable_reclaim_count_objects: Slow: 405881 us
           <...>-3721  [000] ....   106.638445: kbase_mem_evictable_reclaim_count_objects: Slow: 421851 us

...AKA assuming I'm remembering right I saw cases where kbase_mem_evictable_reclaim_count_objects() was taking over 400 ms!

===

In any case: I never proved that speeding kbase_mem_evictable_reclaim_count_objects() helped with anything so I just kinda dropped the patch on the floor.  ...but maybe someone wants to see if the above results are still reproducible and if we should take something like my patch?