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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <20181112225015.jyuro3z3ygavnvrp@zorba>
Date:   Mon, 12 Nov 2018 14:50:15 -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 01:43:33PM -0800, Daniel Walker wrote:
> On Thu, Nov 08, 2018 at 07:47:08PM +0000, David Woodhouse wrote:
> > On Thu, 2018-11-08 at 18:01 +0000, Nikunj Kela (nkela) wrote:
> > >     But we can hypothesise and handwave about it until the cows come home;
> > >     I'd like to see a real test of whether it actually makes a difference
> > >     that we care about.
> > >     
> > >     If it does, one option might be to just build separate versions of
> > >     scan.c for each endianness, since that's the critical path we care
> > >     about.
> > > 
> > > I wonder if this feature is really that important that we need to duplicate the drivers.
> > > Also, it might take some time for me to find some device that I can run the tests with and without this patch.
> > 
> > Hm?
> > 
> > # modprobe mtdram size=16384
> > # mount -tjffs2 mtd0 /mnt
> > # cp -av .git /mnt # until it fills up
> > # umount /mnt
> > # perf record mount -tjffs2 mtd0 /mnt
> > 
> > On my desktop 'perf' only gets about 12 samples from that, so it's not
> > ideal. But you can make the mtdram device bigger, use something other
> > than my shiny new laptop, and use a higher sample frequency from 'perf'
> > and you should be able to get some vaguely meaningful results.
> > 
> 

Made a little mistake. The first tests were with Nikunj's very first version
which was just a pure Kconfig option. I reran the test of the second version and
increased the mtdram space to 100megs.

baseline below,

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.303072 task-clock                #    0.775 CPUs utilized          
                19 context-switches          #    0.189 K/sec                  
                 0 cpu-migrations            #    0.000 K/sec                  
                94 page-faults               #    0.937 K/sec                  
         134135872 cycles                    #    1.337 GHz                     [92.88%]
          29217497 stalled-cycles-frontend   #   21.78% frontend cycles idle    [92.02%]
          10493221 stalled-cycles-backend    #    7.82% backend  cycles idle    [92.05%]
         136740541 instructions              #    1.02  insns per cycle        
                                             #    0.21  stalled cycles per insn [92.04%]
          14639149 branches                  #  145.949 M/sec                   [19.06%]
           1384856 branch-misses             #    9.46% of all branches         [16.29%]

       0.129377322 seconds time elapsed


This is with the mount option changes added.


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.516160 task-clock                #    0.315 CPUs utilized          
                14 context-switches          #    0.139 K/sec                  
                 0 cpu-migrations            #    0.000 K/sec                  
                94 page-faults               #    0.935 K/sec                  
         129255757 cycles                    #    1.286 GHz                     [19.32%]
          26930446 stalled-cycles-frontend   #   20.84% frontend cycles idle    [92.00%]
          10068627 stalled-cycles-backend    #    7.79% backend  cycles idle    [92.05%]
         138000320 instructions              #    1.07  insns per cycle        
                                             #    0.20  stalled cycles per insn [92.04%]
          26158985 branches                  #  260.247 M/sec                   [90.09%]
           1242606 branch-misses             #    4.75% of all branches         [19.24%]

       0.319593555 seconds time elapsed


It looks like the took slightly more than twice as long to mount.

Daniel