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: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20181112234022.r3gyu633ln3bp774@zorba>
Date:   Mon, 12 Nov 2018 15:40:22 -0800
From:   Daniel Walker <danielwa@...co.com>
To:     David Woodhouse <dwmw2@...radead.org>
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, 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

> > 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 ?

Daniel

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ