On Mon, 2018-11-12 at 15:40 -0800, Daniel Walker wrote: > On Mon, Nov 12, 2018 at 03:11:32PM -0800, David Woodhouse wrote: > > On Mon, 2018-11-12 at 14:50 -0800, Daniel Walker wrote: > > > Performance counter stats for 'mount -t jffs2 /dev/mtdblock7 /mnt': > > > > Hm, how many decades will it take for the 'mtdblock' thing to die? > > JFFS2 doesn't use block devices :) > > mount wouldn't mount unless I use it. It complained "not a block device." > > sh-4.2# mount -t jffs2 /dev/mtd7 /mnt > mount: /dev/mtd7 is not a block device Just "mtd7", like in the example I gave before. No /dev/ > > > It looks like the took slightly more than twice as long to mount. > > > > Assuming that's repeatable, it seems moderately suboptimal. > > I don't understand how the cycles are lower, but the time is longer. I suppose > it could be measuring the time including when another process was running and > mount as waiting.. > > Looks like it's not repeatable .. Another run and the time is similar to the > baseline. > > sh-4.2# perf stat -B mount -t jffs2 /dev/mtdblock7 /mnt > jffs2: Flash size not aligned to erasesize, reducing to 99944KiB > > Performance counter stats for 'mount -t jffs2 /dev/mtdblock7 /mnt': > > 100.468768 task-clock # 0.750 CPUs utilized > 14 context-switches # 0.139 K/sec > 0 cpu-migrations # 0.000 K/sec > 94 page-faults # 0.936 K/sec > 132105969 cycles # 1.315 GHz [94.26%] > 27915494 stalled-cycles-frontend # 21.13% frontend cycles idle [91.88%] > 10214813 stalled-cycles-backend # 7.73% backend cycles idle [92.04%] > 137814560 instructions # 1.04 insns per cycle > # 0.20 stalled cycles per insn [92.04%] > 15395620 branches # 153.238 M/sec [19.29%] > 1240507 branch-misses # 8.06% of all branches [17.87%] > > 0.133987804 seconds time elapsed > > > > Should I test increasing the mtdram size ? That can't hurt. We should probably look at the time elapsed before you can *write* to it (when the background scan and crc checking is complete) rather than just reading.