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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 12 Nov 2018 15:43:37 -0800
From:   David Woodhouse <dwmw2@...radead.org>
To:     Daniel Walker <danielwa@...co.com>
Cc:     "Nikunj Kela (nkela)" <nkela@...co.com>,
        Richard Weinberger <richard.weinberger@...il.com>,
        "linux-mtd @ lists . infradead . org" <linux-mtd@...ts.infradead.org>,
        LKML <linux-kernel@...r.kernel.org>,
        "xe-linux-external(mailer list)" <xe-linux-external@...co.com>
Subject: Re: [PATCH] jffs2: implement mount option to configure endianness

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.


Download attachment "smime.p7s" of type "application/x-pkcs7-signature" (5213 bytes)