MTD/flash perfomance statistics

MTD/flash perfomance statistics

[Bruce_Leonard]

We're using UBIFS/UBI/MTD/NAND and we want to find out how much of our 
time is spent accessing the flash.  Are there any tools or is there any 
code in that chain that collects any sort of statistics on flash 
performace/utilization?  I could do something as crude as a counter in my 
NAND driver, but if there's anything more sophisticated that I can just 
"use out of the box" so to speak that would be better.  Thanks.

Bruce

Re: MTD/flash perfomance statistics

[Artem Bityutskiy]

On Tue, 2008-11-11 at 10:08 -0800, Bruce_Leonard@selinc.com wrote:
> We're using UBIFS/UBI/MTD/NAND and we want to find out how much of our 
> time is spent accessing the flash.  Are there any tools or is there any 
> code in that chain that collects any sort of statistics on flash 
> performace/utilization?  I could do something as crude as a counter in my 
> NAND driver, but if there's anything more sophisticated that I can just 
> "use out of the box" so to speak that would be better.  Thanks.

Not sure what exactly you need, but probably you want oprofile?

-- 
Best regards,
Artem Bityutskiy (Битюцкий Артём)

Re: MTD/flash perfomance statistics

[Bruce_Leonard]

Artem Bityutskiy <dedekind@infradead.org> wrote on 11/11/2008 09:38:09 PM:

> On Tue, 2008-11-11 at 10:08 -0800, Bruce_Leonard@selinc.com wrote:
> > We're using UBIFS/UBI/MTD/NAND and we want to find out how much of our 

> > time is spent accessing the flash.  Are there any tools or is there 
any 
> > code in that chain that collects any sort of statistics on flash 
> > performace/utilization?  I could do something as crude as a counter in 
my 
> > NAND driver, but if there's anything more sophisticated that I can 
just 
> > "use out of the box" so to speak that would be better.  Thanks.
> 
> Not sure what exactly you need, but probably you want oprofile?
> 

Well, I'm not sure exactly what I need either :).  What the 
application/diagnostic guys are looking for is a way to determine (to some 
degree) how "hard" we're "beating" on the flash.  How much of the 
processor's time are we spending just reading and writting to the flash as 
well as how often.  I think what they're after is a means to try and 
guestimate how long our flash will last given how frequently we're 
writting/erasing it.  We'll take a look at oprofile.  Thanks.

Bruce

Re: MTD/flash perfomance statistics

[Bruce_Leonard]

Hi Artem,

Artem Bityutskiy <dedekind@infradead.org> wrote on 11/11/2008 09:38:09 PM:

> On Tue, 2008-11-11 at 10:08 -0800, Bruce_Leonard@selinc.com wrote:
> > We're using UBIFS/UBI/MTD/NAND and we want to find out how much of our 

> > time is spent accessing the flash.  Are there any tools or is there 
any 
> > code in that chain that collects any sort of statistics on flash 
> > performace/utilization?  I could do something as crude as a counter in 
my 
> > NAND driver, but if there's anything more sophisticated that I can 
just 
> > "use out of the box" so to speak that would be better.  Thanks.
> 
> Not sure what exactly you need, but probably you want oprofile?
> 
> -- 
> Best regards,
> Artem Bityutskiy (Битюцкий Артём)
> 

I finally got the app guys to pin down exactly what they want.  Here's a 
copy of the email I got from them:

"They appear to be going the wrong way.  We're looking for runtime 
diagnostic-y type of things (i.e. Number of writes to the flash, number of 
bad blocks, statistics from the wear leveler to see how the wear leveling 
is going, etc.)  Things that don't take a lot of CPU time to do, like 
counters, that we can use to give us information on what a customer's box 
may or may not be doing in the field.  A ready example that comes to mind 
is ethernet statistics, bytes/packets sent/recieved, error counts, etc. Or 
if you want a storage analog, things like you would see in 
/sys/block/hda/stat but adapted to make sense in Flash storage."

Is there anything like that for UBIFS/UBI/MTD/NAND that you're aware of? 
Thanks.

BTW, we're happily up and running UBIFS on a 2GiB flash part with no 
errors.  Mount times are pretty resonable.  I don't have current times 
because I've been about three kernel versions ahead of everyone else so 
the stuff they've all been using until recently didn't have some of the 
speed improvments.  If I get the time (and remember to do it ;)  ) I'll 
try to float some numbers out there.

Thanks for all the help over the last several months getting my stuff 
going.  It's been great working with you.

Bruce

Re: MTD/flash perfomance statistics

[Artem Bityutskiy]

On Mon, 2008-11-17 at 15:42 -0800, Bruce_Leonard@selinc.com wrote:
> "They appear to be going the wrong way.  We're looking for runtime 
> diagnostic-y type of things (i.e. Number of writes to the flash, number of 
> bad blocks, statistics from the wear leveler to see how the wear leveling 
> is going, etc.)  Things that don't take a lot of CPU time to do, like 
> counters, that we can use to give us information on what a customer's box 
> may or may not be doing in the field.  A ready example that comes to mind 
> is ethernet statistics, bytes/packets sent/recieved, error counts, etc. Or 
> if you want a storage analog, things like you would see in 
> /sys/block/hda/stat but adapted to make sense in Flash storage."

I see. No, we do not really provide this statistics, just because no one
needed this. Please, give me the list of what exactly you would like to
know, and I will try to implement this for you.

> BTW, we're happily up and running UBIFS on a 2GiB flash part with no 
> errors.  Mount times are pretty resonable.  I don't have current times 
> because I've been about three kernel versions ahead of everyone else so 
> the stuff they've all been using until recently didn't have some of the 
> speed improvments.  If I get the time (and remember to do it ;)  ) I'll 
> try to float some numbers out there.

Cool, of course numbers and hardware information (CPU, flash type, I/O
speed) is appreciated.

> Thanks for all the help over the last several months getting my stuff 
> going.  It's been great working with you.

No problem.

-- 
Best regards,
Artem Bityutskiy (Битюцкий Артём)

Re: MTD/flash perfomance statistics

[Bruce_Leonard]

Hi Artem,

Artem Bityutskiy <dedekind@infradead.org> wrote on 11/18/2008 12:05:09 AM:

> On Mon, 2008-11-17 at 15:42 -0800, Bruce_Leonard@selinc.com wrote:
> > "They appear to be going the wrong way.  We're looking for runtime 
> > diagnostic-y type of things (i.e. Number of writes to the flash, 
number of 
> > bad blocks, statistics from the wear leveler to see how the wear 
leveling 
> > is going, etc.)  Things that don't take a lot of CPU time to do, like 
> > counters, that we can use to give us information on what a customer's 
box 
> > may or may not be doing in the field.  A ready example that comes to 
mind 
> > is ethernet statistics, bytes/packets sent/recieved, error counts, 
etc. Or 
> > if you want a storage analog, things like you would see in 
> > /sys/block/hda/stat but adapted to make sense in Flash storage."
> 
> I see. No, we do not really provide this statistics, just because no one
> needed this. Please, give me the list of what exactly you would like to
> know, and I will try to implement this for you.
> 

Okay, a bit more info has trickled in from the application guys.  We don't 
know exactly what we want, but something is better than nothing :).  What 
we're looking for is information regarding how often we're 
reading/writting the flash, how many factory bad blocks there are, how 
many bad blocks have developed over time.  We want to be able to make a 
rough estimate of how long a part is going to last, based on the part 
itself (i.e., number of bad blocks) and any given customer's usage of the 
product (i.e., how often is the part being accessed, how many new bad 
blocks have developed, how well is the UBI wear leveling working) wich 
will vary from customer to customer depending on how they're using the 
product.  It doesn't have to be anything sophisticated and I think 
primarily what the app guys are after are things that UBI probably already 
tracks for the wear leveling (i.e., number of writes and bad blocks).

Does this help?

Thanks.

Bruce

Re: MTD/flash perfomance statistics

[Artem Bityutskiy]

On Fri, 2008-11-21 at 10:41 -0800, Bruce_Leonard@selinc.com wrote:
> Okay, a bit more info has trickled in from the application guys.  We don't 
> know exactly what we want, but something is better than nothing :).  What 
> we're looking for is information regarding how often we're 
> reading/writting the flash, how many factory bad blocks there are, how 
> many bad blocks have developed over time.

Well, this should be MTD feature, not UBI/UBIFS feature. And if you want
to preserve I/O statistics over reboots, you have to save it on flash,
which is not light-weight anymore.

>   We want to be able to make a 
> rough estimate of how long a part is going to last, based on the part 
> itself (i.e., number of bad blocks)

There is maximum erase counter available in /sys/class/ubi/ubi0/max_ec,
which you may use to judge how close the flash to EOL.

/sys/class/ubi/ubi0/bad_peb_count - count of bad PEB on the MTD device
this UBI device sits on. It includes both factory-marked and dynamically
appeared. There is way to distinguish between factory and non-factory
bad blocks in MTD.

/sys/class/ubi/ubi0/reserved_for_bad tells you number of eraseblocks
reserved for bad block handling. If it becomes zero, you may have
troubles when the next bad block appears, so you may watch this value as
well.

>  and any given customer's usage of the 
> product (i.e., how often is the part being accessed, how many new bad 
> blocks have developed, how well is the UBI wear leveling working)

Well, it is easy to add more statistics, but preserving it between
reboots is not easy.


>  wich 
> will vary from customer to customer depending on how they're using the 
> product.  It doesn't have to be anything sophisticated and I think 
> primarily what the app guys are after are things that UBI probably already 
> tracks for the wear leveling (i.e., number of writes and bad blocks).

Well, loot at the above sysfs-provided info, may be it is enough?

-- 
Best regards,
Artem Bityutskiy (Битюцкий Артём)