kernel defconfig, CONFIG_MTD_NAND_VERIFY_WRITE

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

kernel defconfig, CONFIG_MTD_NAND_VERIFY_WRITE

Gennady Kupava
hi all,

I still don't beleive our device should be so slow as it is now. I'll
try to investigate performance impact of several kernel option. I
expect, changes will be introduced to defalt config for distributions.
Here is first one CONFIG_MTD_NAND_VERIFY_WRITE.

Now it is enabled.

I build kernel with and without this option, and did read and write
tests to /dev/mtd6 and /dev/mtdblock6. all tests done with dd
to/from /dev/zero bs=256k count=200. read is just for check.

most data in Mb/s.

              mtd6-rd, mtd6-wt, mtdblock6-rd, mtdblock6-wt

option on     5.2,     4.8,     2.6,          900kb/s

option off    5.2,     2.4,     2.6,      712kb/s

I think mtdblock speed is good for approximation of real performance
impact of this option.

Think this option should be removed from defconfig, as it causes major
write slowdown (up to 2x).

Gennady.



Reply | Threaded
Open this post in threaded view
|

Re: kernel defconfig, CONFIG_MTD_NAND_VERIFY_WRITE

Patryk Benderz
Dnia 2010-01-06, śro o godzinie 12:49 +0300, Gennady Kupava pisze:

> hi all,
>
> I still don't beleive our device should be so slow as it is now. I'll
> try to investigate performance impact of several kernel option. I
> expect, changes will be introduced to defalt config for distributions.
> Here is first one CONFIG_MTD_NAND_VERIFY_WRITE.
>
> Now it is enabled.
>
> I build kernel with and without this option, and did read and write
> tests to /dev/mtd6 and /dev/mtdblock6. all tests done with dd
> to/from /dev/zero bs=256k count=200. read is just for check.
>
> most data in Mb/s.
>
>               mtd6-rd, mtd6-wt, mtdblock6-rd, mtdblock6-wt
>
> option on     5.2,     4.8,     2.6,          900kb/s
>
> option off    5.2,     2.4,     2.6,      712kb/s
>
Well, if this test was repeated several times with similar results, it
might be worth to disable this option IMHO. Only one thing makes me
dither. Will this be safe? I mean, what if there is some software which
takes advantage of this option? Maybe some kind of software which
verifies (using this kernel option) what it writes to device?
Just a thought...

--
Patryk "LeadMan" Benderz
Linux Registered User #377521
()  ascii ribbon campaign - against html e-mail
/\  www.asciiribbon.org   - against proprietary attachments


Email secured by Check Point

Reply | Threaded
Open this post in threaded view
|

Re: kernel defconfig, CONFIG_MTD_NAND_VERIFY_WRITE

Gennady Kupava
Hi, patryk

В Срд, 06/01/2010 в 16:16 +0100, Patryk Benderz пишет:
> >
> Well, if this test was repeated several times with similar results, it
> might be worth to disable this option IMHO. Only one thing makes me
> dither. Will this be safe?

I am not 100% sure, as I am not mtd dev, but in other configs have this
option sometimes disabled. also we have some kind of hw ecc.

> I mean, what if there is some software which
> takes advantage of this option?
> Maybe some kind of software which verifies (using this kernel option) what it writes to device?

no, this is small chuck of code which just reads data after each write i
think if some software depend on it we'll just idetify it and enable
this again.

> Just a thought...
>

gennady


Reply | Threaded
Open this post in threaded view
|

Re: kernel defconfig, CONFIG_MTD_NAND_VERIFY_WRITE

Nelson Castillo-2
On Wed, Oct 6, 2010 at 3:57 PM, Gennady Kupava <[hidden email]> wrote:

> Hi, patryk
>
> В Срд, 06/01/2010 в 16:16 +0100, Patryk Benderz пишет:
>> >
>> Well, if this test was repeated several times with similar results, it
>> might be worth to disable this option IMHO. Only one thing makes me
>> dither. Will this be safe?
>
> I am not 100% sure, as I am not mtd dev, but in other configs have this
> option sometimes disabled. also we have some kind of hw ecc.

I don't know the details but HW ecc is disabled in the FR.

static struct s3c2410_platform_nand gta02_nand_info = {
        .tacls          = 0,
        .twrph0         = 25,
        .twrph1         = 15,
        .nr_sets        = ARRAY_SIZE(gta02_nand_sets),
        .sets           = gta02_nand_sets,
        .software_ecc   = 1,
};

Check drivers/mtd/nand/s3c2410.c if in doubt.

Reply | Threaded
Open this post in threaded view
|

Re: kernel defconfig, CONFIG_MTD_NAND_VERIFY_WRITE

Gennady Kupava
В Срд, 06/01/2010 в 13:53 -0500, Nelson Castillo пишет:

> On Wed, Oct 6, 2010 at 3:57 PM, Gennady Kupava <[hidden email]> wrote:
> > Hi, patryk
> >
> > В Срд, 06/01/2010 в 16:16 +0100, Patryk Benderz пишет:
> >> >
> >> Well, if this test was repeated several times with similar results, it
> >> might be worth to disable this option IMHO. Only one thing makes me
> >> dither. Will this be safe?
> >
> > I am not 100% sure, as I am not mtd dev, but in other configs have this
> > option sometimes disabled. also we have some kind of hw ecc.
>
> I don't know the details but HW ecc is disabled in the FR.
>
> static struct s3c2410_platform_nand gta02_nand_info = {
>         .tacls          = 0,
>         .twrph0         = 25,
>         .twrph1         = 15,
>         .nr_sets        = ARRAY_SIZE(gta02_nand_sets),
>         .sets           = gta02_nand_sets,
>         .software_ecc   = 1,
> };
>
> Check drivers/mtd/nand/s3c2410.c if in doubt.

First, Paul already committed patch,

second,

strange, but in config it is enabled:
CONFIG_MTD_NAND_S3C2410_HWECC=y

CONFIG_MTD_NAND_S3C2410_HWECC:
Enable the use of the S3C2410's internal ECC generator when
using NAND. Early versions of the chip have had problems with
incorrect ECC generation, and if using these, the default of
software ECC is preferable.

even more interesting, why it is disabled? according to datasheet
SC32442B have one. next thing for investigation.

gennady




Reply | Threaded
Open this post in threaded view
|

Re: kernel defconfig, CONFIG_MTD_NAND_VERIFY_WRITE

Nelson Castillo-2
On Wed, Oct 6, 2010 at 5:13 PM, Gennady Kupava <[hidden email]> wrote:

> В Срд, 06/01/2010 в 13:53 -0500, Nelson Castillo пишет:
>> On Wed, Oct 6, 2010 at 3:57 PM, Gennady Kupava <[hidden email]> wrote:
>> > Hi, patryk
>> >
>> > В Срд, 06/01/2010 в 16:16 +0100, Patryk Benderz пишет:
>> >> >
>> >> Well, if this test was repeated several times with similar results, it
>> >> might be worth to disable this option IMHO. Only one thing makes me
>> >> dither. Will this be safe?
>> >
>> > I am not 100% sure, as I am not mtd dev, but in other configs have this
>> > option sometimes disabled. also we have some kind of hw ecc.
>>
>> I don't know the details but HW ecc is disabled in the FR.
>>
>> static struct s3c2410_platform_nand gta02_nand_info = {
>>         .tacls          = 0,
>>         .twrph0         = 25,
>>         .twrph1         = 15,
>>         .nr_sets        = ARRAY_SIZE(gta02_nand_sets),
>>         .sets           = gta02_nand_sets,
>>         .software_ecc   = 1,
>> };
>>
>> Check drivers/mtd/nand/s3c2410.c if in doubt.
>
> First, Paul already committed patch,
>
> second,
>
> strange, but in config it is enabled:
> CONFIG_MTD_NAND_S3C2410_HWECC=y

Check s3c2410.c to see what this option does.

#ifdef CONFIG_MTD_NAND_S3C2410_HWECC
static int hardware_ecc = 1;
#else
static int hardware_ecc = 0;
#endif


AFAIK this is not doing anything in the more OM recent kernels
(>2.6.31) because the NAND configuration in mach-gta02.c overrides
this setting.

See s3c2410.c:
if (!info->platform->software_ecc && hardware_ecc) {
 ...
}

> even more interesting, why it is disabled? according to datasheet
> SC32442B have one. next thing for investigation.

You might want to search old discussions here in the mailing list to
check why things were done this way.
It's the same in andy-tracking (with different code).

Reply | Threaded
Open this post in threaded view
|

Re: kernel defconfig, CONFIG_MTD_NAND_VERIFY_WRITE

Werner Almesberger
In reply to this post by Gennady Kupava
Gennady Kupava wrote:
> even more interesting, why it is disabled? according to datasheet
> SC32442B have one. next thing for investigation.

I don't remember the exact reason why we disabled it in the first
place, but I think it was some bug in the ECC calculation. There
was also an API change in the kernel that caused incorrect
"corrections" to be applied.

Eventually, that problem was solved, but then we had the issue of
u-boot and kernel disagreeing on the ECC (sw and hw differ). Only
if updating both programs, you would get the correct result.

This coordinated transition was further complicated by having an
immutable u-boot in NOR. Murphy is watchful :)

So, in the end we never made the switch, even though the technical
reason for using software ECC had disappeared by then. (Except
for u-boot in NOR, of course.)

- Werner

Reply | Threaded
Open this post in threaded view
|

Re: kernel defconfig, CONFIG_MTD_NAND_VERIFY_WRITE

Christoph Mair
In reply to this post by Nelson Castillo-2
On Wednesday 06 January 2010 22:02:18 Nelson Castillo wrote:

> On Wed, Oct 6, 2010 at 5:13 PM, Gennady Kupava <[hidden email]> wrote:
> > В Срд, 06/01/2010 в 13:53 -0500, Nelson Castillo пишет:
> >> On Wed, Oct 6, 2010 at 3:57 PM, Gennady Kupava <[hidden email]> wrote:
> >> > Hi, patryk
> >> >
> >> > В Срд, 06/01/2010 в 16:16 +0100, Patryk Benderz пишет:
> >> >> Well, if this test was repeated several times with similar results,
> >> >> it might be worth to disable this option IMHO. Only one thing makes
> >> >> me dither. Will this be safe?
> >> >
> >> > I am not 100% sure, as I am not mtd dev, but in other configs have
> >> > this option sometimes disabled. also we have some kind of hw ecc.
> >>
> >> I don't know the details but HW ecc is disabled in the FR.
> >>
> >> static struct s3c2410_platform_nand gta02_nand_info = {
> >>         .tacls          = 0,
> >>         .twrph0         = 25,
> >>         .twrph1         = 15,
> >>         .nr_sets        = ARRAY_SIZE(gta02_nand_sets),
> >>         .sets           = gta02_nand_sets,
> >>         .software_ecc   = 1,
> >> };
> >>
> >> Check drivers/mtd/nand/s3c2410.c if in doubt.
> >
> > First, Paul already committed patch,
> >
> > second,
> >
> > strange, but in config it is enabled:
> > CONFIG_MTD_NAND_S3C2410_HWECC=y
>
> Check s3c2410.c to see what this option does.
>
> #ifdef CONFIG_MTD_NAND_S3C2410_HWECC
> static int hardware_ecc = 1;
> #else
> static int hardware_ecc = 0;
> #endif
>
>
> AFAIK this is not doing anything in the more OM recent kernels
> (>2.6.31) because the NAND configuration in mach-gta02.c overrides
> this setting.
>
> See s3c2410.c:
> if (!info->platform->software_ecc && hardware_ecc) {
>  ...
> }
In my 2.6.32 kernel I enabled CONFIG_MTD_NAND_S3C2410_HWECC, set
.software_ecc=0 and made some speed tests. The Results:
http://pastebin.ca/1740974
Some operations are slightly faster. I did not observe I/O errors or wrong
checksums.

Best regards,
  Christoph

Reply | Threaded
Open this post in threaded view
|

Re: kernel defconfig, CONFIG_MTD_NAND_VERIFY_WRITE

Gennady Kupava
Hi, Cristoph.

something still (i mean from times Werner talking about) wrong with
hardware ecc, I can't read/write mtdblock on 2.6.29.

                           mtd6-rd, mtd6-wt, mtdblock6-rd, mtdblock6-wt
original (from old test):  5.2,     4.8,     2.6,          900kb/s
with hw ecc + nonanddebug: 6.4,     4.9,     error    error

and got following errors while testing mtdblock (time dd
if=/dev/mtdblock6 of=/dev/zero bs=256k count=200)

[21474773.805000] end_request: I/O error, dev mtdblock6, sector 256
[21474773.805000] Buffer I/O error on device mtdblock6, logical block 32

i'll try to undertand how this happened, so wait with commit please.

gennady

В Чтв, 07/01/2010 в 03:58 +0100, Christoph Mair пишет:

> On Wednesday 06 January 2010 22:02:18 Nelson Castillo wrote:
> > On Wed, Oct 6, 2010 at 5:13 PM, Gennady Kupava <[hidden email]> wrote:
> > > В Срд, 06/01/2010 в 13:53 -0500, Nelson Castillo пишет:
> > >> On Wed, Oct 6, 2010 at 3:57 PM, Gennady Kupava <[hidden email]> wrote:
> > >> > Hi, patryk
> > >> >
> > >> > В Срд, 06/01/2010 в 16:16 +0100, Patryk Benderz пишет:
> > >> >> Well, if this test was repeated several times with similar results,
> > >> >> it might be worth to disable this option IMHO. Only one thing makes
> > >> >> me dither. Will this be safe?
> > >> >
> > >> > I am not 100% sure, as I am not mtd dev, but in other configs have
> > >> > this option sometimes disabled. also we have some kind of hw ecc.
> > >>
> > >> I don't know the details but HW ecc is disabled in the FR.
> > >>
> > >> static struct s3c2410_platform_nand gta02_nand_info = {
> > >>         .tacls          = 0,
> > >>         .twrph0         = 25,
> > >>         .twrph1         = 15,
> > >>         .nr_sets        = ARRAY_SIZE(gta02_nand_sets),
> > >>         .sets           = gta02_nand_sets,
> > >>         .software_ecc   = 1,
> > >> };
> > >>
> > >> Check drivers/mtd/nand/s3c2410.c if in doubt.
> > >
> > > First, Paul already committed patch,
> > >
> > > second,
> > >
> > > strange, but in config it is enabled:
> > > CONFIG_MTD_NAND_S3C2410_HWECC=y
> >
> > Check s3c2410.c to see what this option does.
> >
> > #ifdef CONFIG_MTD_NAND_S3C2410_HWECC
> > static int hardware_ecc = 1;
> > #else
> > static int hardware_ecc = 0;
> > #endif
> >
> >
> > AFAIK this is not doing anything in the more OM recent kernels
> > (>2.6.31) because the NAND configuration in mach-gta02.c overrides
> > this setting.
> >
> > See s3c2410.c:
> > if (!info->platform->software_ecc && hardware_ecc) {
> >  ...
> > }
> In my 2.6.32 kernel I enabled CONFIG_MTD_NAND_S3C2410_HWECC, set
> .software_ecc=0 and made some speed tests. The Results:
> http://pastebin.ca/1740974
> Some operations are slightly faster. I did not observe I/O errors or wrong
> checksums.
>
> Best regards,
>   Christoph
>



Reply | Threaded
Open this post in threaded view
|

Re: kernel defconfig, CONFIG_MTD_NAND_VERIFY_WRITE

Christoph Mair
On Friday 08 October 2010 15:27:21 you wrote:

> Hi, Cristoph.
>
> something still (i mean from times Werner talking about) wrong with
> hardware ecc, I can't read/write mtdblock on 2.6.29.
>
>                            mtd6-rd, mtd6-wt, mtdblock6-rd, mtdblock6-wt
> original (from old test):  5.2,     4.8,     2.6,          900kb/s
> with hw ecc + nonanddebug: 6.4,     4.9,     error    error
>
> and got following errors while testing mtdblock (time dd
> if=/dev/mtdblock6 of=/dev/zero bs=256k count=200)
>
> [21474773.805000] end_request: I/O error, dev mtdblock6, sector 256
> [21474773.805000] Buffer I/O error on device mtdblock6, logical block 32
>
> i'll try to undertand how this happened, so wait with commit please.
I do not have commit rights anyway, so nothing to worry about ;) I'm just
trying random stuff to find possible bottlenecks.

Christoph

Reply | Threaded
Open this post in threaded view
|

Re: kernel defconfig, CONFIG_MTD_NAND_VERIFY_WRITE

Gennady Kupava
В Птн, 08/01/2010 в 14:29 +0100, Christoph Mair пишет:

> On Friday 08 October 2010 15:27:21 you wrote:
> > Hi, Cristoph.
> >
> > something still (i mean from times Werner talking about) wrong with
> > hardware ecc, I can't read/write mtdblock on 2.6.29.
> >
> >                            mtd6-rd, mtd6-wt, mtdblock6-rd, mtdblock6-wt
> > original (from old test):  5.2,     4.8,     2.6,          900kb/s
> > with hw ecc + nonanddebug: 6.4,     4.9,     error    error
> >
> > and got following errors while testing mtdblock (time dd
> > if=/dev/mtdblock6 of=/dev/zero bs=256k count=200)
> >
> > [21474773.805000] end_request: I/O error, dev mtdblock6, sector 256
> > [21474773.805000] Buffer I/O error on device mtdblock6, logical block 32
> >
> > i'll try to undertand how this happened, so wait with commit please.
> I do not have commit rights anyway, so nothing to worry about ;) I'm just
> trying random stuff to find possible bottlenecks.
>
> Christoph

I can share mine ideas what to try also, as understanding that ecc stuff
and fighting to exclude debug info and preemption can take a while:

I've saw 2 different floating point engines, fast one and pricise one,
and as we are not building plane we for sure may use fast one. My wild
guess this might help much to tangogps for example. I don't know
(yet :) ) who  and how handle softfloat on arm, but this might speedup
floating operations, as this is weak point of our device.

Also, i see our kernel using HZ of 200, which extremly high in my
optinion for device there cache is flashed on each task switch. I think
decreasing it down to classic 60 which worked for ages on older kernels
will work excellent, as we not playing fps and do not do professional
audio recordings.

but all this is just idea, may or may not work as i do not understand
this in details

gennady