UBI fastmap used PEB search

[Brian Pomerantz]

On May 1, 2013, at 2:04 PM, richard -rw- weinberger <richard.weinberger at gmail.com> wrote:

> 
> Yeah, the break makes sense. I simply forgot it.
> As pnum has to be unique we can stop processing after the found a matching pnum.
> Do you have some numbers how much your fix improves the overall performance?

Off the top of my head (that was last week, I need to rerun the tests to get real numbers), with two volumes at 400MB each almost filled with UBIFS, that test in the loop for pnum was hit more than 2,200,000 times.  With the break in there it was more like 1,200,000 times.  This knocked off some 100ms off my attach time.

> 
> The current fastmap implementation is more or less a prove of concept
> implementation,
> I'm sure there is potential to gain more performance.
> Patches are very welcome!

I think I'll try using a RB tree to see if the overhead is offset by the search time savings.  At the very least, the attach time would be more consistent no matter how full the volumes get.

Another idea I was kicking around that might be easier than passing processed attach data to the kernel is short circuiting the attach process in u-boot to only process the volume that contains the kernel.  This would take significantly less time than processing all of the volumes.

> 
> Thanks,
> //richard
> 
> P.s: Can you please re-submit your patch in the proper "Linux kernel" format?
> See: Documentation/SubmittingPatches
> tl;dr: use scripts/checkpatch.pl and git send-email

Okay, just resubmitted.  It's been a while so hopefully I got it right. :)


--Brian