While collecting performance data for another project (using Caroline for reference), I triggered an OOM that caused a panic in kernel_fs_Punybench twice. It looks like this has been triggered before ( crbug.com/221726 ), and maybe I just got unlucky with the writeback speed here.

Perhaps we should set min_filelist_kbytes to 0 during this benchmark to ease the memory pressure a bit?

What's strange is that this doesn't happen if the eMMC part is configured as (HS400, 8-bit) or (HS200, 4-bit). I only encounter this with (HS200, 8-bit):
localhost ~ # cat /sys/kernel/debug/mmc0/ios
clock:          200000000 Hz
actual clock:   200000000 Hz
vdd:            7 (1.65 - 1.95 V)
bus mode:       2 (push-pull)
chip select:    0 (don't care)
power mode:     2 (on)
bus width:      3 (8 bits)
timing spec:    9 (mmc HS200)
signal voltage: 0 (1.80 V)

[ 1469.068158] uread invoked oom-killer: gfp_mask=0x10200da, order=0, oom_score_adj=-1000
[ 1469.068193] uread cpuset=/ mems_allowed=0

[ 1469.068378] Call Trace:
[ 1469.068405]  [<ffffffffaa4a1520>] dump_stack+0x4e/0x71
[ 1469.068428]  [<ffffffffaa4a066f>] dump_header.isra.10+0xa5/0x220
[ 1469.068457]  [<ffffffffa9f119fa>] out_of_memory+0x217/0x2d7
[ 1469.068483]  [<ffffffffa9f1534a>] __alloc_pages_nodemask+0x8cc/0x911
[ 1469.068509]  [<ffffffffa9f0eea3>] pagecache_get_page+0xd1/0x152
[ 1469.068533]  [<ffffffffa9f0ef56>] grab_cache_page_write_begin+0x32/0x49
[ 1469.068561]  [<ffffffffa9fbb43e>] ext4_da_write_begin+0x16e/0x288
[ 1469.068585]  [<ffffffffa9f0e231>] generic_perform_write+0xce/0x1d7
[ 1469.068615]  [<ffffffffa9f68dbc>] ? file_update_time+0x43/0xd1
[ 1469.068639]  [<ffffffffa9f0ff7b>] __generic_file_write_iter+0x188/0x1d9
[ 1469.068685]  [<ffffffffa9fb257e>] ext4_file_write_iter+0x2bc/0x364
[ 1469.068753]  [<ffffffffa9ea7f4a>] ? __srcu_read_unlock+0xc/0x1a
[ 1469.068780]  [<ffffffffa9f523f9>] new_sync_write+0x8b/0xc3
[ 1469.068806]  [<ffffffffa9f52be0>] vfs_write+0xb0/0xf5
[ 1469.068830]  [<ffffffffa9f5326e>] ? SyS_write+0x8d/0x9f
[ 1469.068853]  [<ffffffffa9f5323e>] SyS_write+0x5d/0x9f
[ 1469.068879]  [<ffffffffaa4a68c4>] ? system_call_after_swapgs+0x21/0x5d
[ 1469.068917]  [<ffffffffaa4a691c>] system_call_fastpath+0x1c/0x21

[ 1469.069242] active_anon:24840 inactive_anon:8140 isolated_anon:0
[ 1469.069242]  active_file:11051 inactive_file:77613 isolated_file:0
[ 1469.069242]  unevictable:791736 dirty:25210 writeback:17437 unstable:0
[ 1469.069242]  free:42285 slab_reclaimable:6891 slab_unreclaimable:6186
[ 1469.069242]  mapped:10920 shmem:15374 pagetables:2502 bounce:0
[ 1469.069242]  free_cma:0


This appears to be the corresponding test logic:
    def _uread(self, prefix, file):
        """Read a large file.

        @param prefix: prefix to use on name/value pair for identifying results
        @param file: file path to use for test

        The size should be picked so the file will
        not fit in memory.

        Example results:
          size=8589934592 n=1 55.5 3. timer avg= 55.5 stdv=0.0693 147.6 MiB/s
          size=8589934592 n=1 55.6 4. timer avg= 55.5 stdv=0.0817 147.5 MiB/s
        """
        args = '-f %s' % file
        result = self._run('uread', args)
        r1 = re.search(r"[^\s]+ MiB/s.*$", result)
        r2 = re.search(re_float, r1.group(0))
        mib_s = r2.group(0)
        self.write_perf_keyval({prefix + 'uread_MiB_s': mib_s})