Re: [PATCH] jffs2: implement mount option to configure endianness

[David Woodhouse]

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.

Attachment: smime.p7s
Description: S/MIME cryptographic signature