Slow NAND + JFFS2
Hi,
I'm using a 256 MiB NAND Flash from ST -> Manufacturer ID: 0x20, Chip ID: 0xda (ST Micro NAND 256MiB 3,3V 8-bit) with JFFS2. The filesystem is mounted as rootfs and the size is around 60 megs.
Filesystem operations seem very slow to me. Such as:
It takes almost 1 and a half minutes to copy a 30 meg file. Mounting the filesystem takes around 1 minute.
# ls -lh -rw-r--r-- 1 root root 30.3M Jan 1 00:05 gcc.tgz # time cp gcc.tgz 1 real 1m 22.37s user 0m 0.09s sys 1m 22.22s #
This seemed really slow to me, but I don't have any other benchmarks. Can someone comment on these values ?
The processor is at32ap7000 from Atmel, running at 160 MHz.
I'm running kernel 2.6.20.1 with cpu related patches from Atmel and our own nand patches which are almost the replica of at91_nand.c (I can send it if you need)
I also changed the read enable and write enable pulse timings according to the minimum values stated in NAND flash's datasheet.
If this copy/mount time are really slow as I think, where should I check ? Is this a JFFS2 related issue or should I try to find some problems in our nand driver or ... ?
Best regards,
Semih Hazar
Quoted 10 lines · Semih Hazar
Hi,
I'm using a 256 MiB NAND Flash from ST -> Manufacturer ID:
0x20, Chip
ID:0xda(ST Micro NAND 256MiB 3,3V 8-bit) with JFFS2. The filesystem is mounted as rootfs and the size is around 60 megs.Filesystem operations seem very slow to me. Such as:
It takes almost 1 and a half minutes to copy a 30 meg file. Mounting the filesystem takes around 1 minute.
Given your CPU speed and the size of the files involved, these timings seem to be normal to me.
You might want to try using summary support to speed up mount time (at the cost of some additional used space). I'm not entirely sure you can speed up the copy time of your file though.
josh
Hi,
You may try to clarify if compression is off.
Quoted 36 lines
Hi,
I'm using a 256 MiB NAND Flash from ST -> Manufacturer ID:
0x20, Chip ID:0xda(ST Micro NAND 256MiB 3,3V 8-bit) with JFFS2. The filesystem is mounted as rootfs and the size is around 60 megs.Filesystem operations seem very slow to me. Such as:
It takes almost 1 and a half minutes to copy a 30 meg file. Mounting the filesystem takes around 1 minute.
# ls -lh -rw-r--r-- 1 root root 30.3M Jan 1 00:05 gcc.tgz # time cp gcc.tgz 1 real 1m 22.37s user 0m 0.09s sys 1m 22.22s #This seemed really slow to me, but I don't have any other benchmarks. Can someone comment on these values ?
The processor is at32ap7000 from Atmel, running at 160 MHz.
I'm running kernel 2.6.20.1 with cpu related patches from Atmel and our own nand patches which are almost the replica ofat91_nand.c(I can send it if you need)I also changed the read enable and write enable pulse timings according to the minimum values stated in NAND flash's datasheet.
If this copy/mount time are really slow as I think, where should I check ? Is this a JFFS2 related issue or should I try to find some problems in our nand driver or ... ?
Best regards,
Semih Hazar______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
Quoted 1 line · akorolev
You may try to clarify if compression is off.
Setting compression mode to "no compression" speeds it a lot.
This time copying a 40 meg file takes 21 seconds. (from NAND to NAND as in the first case)
Thanks
Quoted 5 lines · On Wed, 25 Apr 2007 18:36:26 +0300 Semih Hazar <[email protected]> wrote:
Quoted 1 line · akorolev
You may try to clarify if compression is off.
Setting compression mode to "no compression" speeds it a lot. This time copying a 40 meg file takes 21 seconds. (from NAND to NAND as in the first case)
Interesting. I suspect the zlib code might thrash the TLB quite a bit on the ap7000 because of the rather large workspace struct which is allocated using vmalloc().
Until we get around to supporting larger page sizes for vmalloc, could you try a different compressor (assuming you're currently using zlib)?
Haavard
Quoted 7 lines · Haavard Skinnemoen
Interesting. I suspect the zlib code might thrash the TLB quite a bit on the ap7000 because of the rather large workspace struct which is allocated using
vmalloc().Until we get around to supporting larger page sizes for vmalloc, could you try a different compressor (assuming you're currently using zlib)?
Zlib or rtime, not sure. I'll try other compressors and let you know the benchmarks.