[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <b797e897960c3c047dfc7874615358a5443038a8.camel@infradead.org>
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)
Powered by blists - more mailing lists