On ven., juin 16, 2023 at 13:56, Mattijs Korpershoek <mkorpersh...@baylibre.com> wrote:
> Hi Gary, Sean, > > On lun., nov. 21, 2022 at 10:09, Sean Anderson <sean.ander...@seco.com> wrote: > >> On 11/21/22 09:50, Gary Bisson wrote: >>> Hi, >>> >>> On Fri, Nov 18, 2022 at 10:36:58AM -0500, Sean Anderson wrote: >>>> On 11/18/22 07:13, Gary Bisson wrote: >>>> > This reverts commit 62649165cb02ab95b57360bb362886935f524f26. >>>> > >>>> > The patch decreased the write performance quite a bit. >>>> > Here is an example on an i.MX 8M Quad platform. >>>> > - Before the revert: >>>> > Sending sparse 'vendor' 1/2 (516436 KB) OKAY [ 5.113s] >>>> > Writing 'vendor' OKAY [128.335s] >>>> > Sending sparse 'vendor' 2/2 (76100 KB) OKAY [ 0.802s] >>>> > Writing 'vendor' OKAY [ 27.902s] >>>> > - After the revert: >>>> > Sending sparse 'vendor' 1/2 (516436 KB) OKAY [ 5.310s] >>>> > Writing 'vendor' OKAY [ 18.041s] >>>> > Sending sparse 'vendor' 2/2 (76100 KB) OKAY [ 1.244s] >>>> > Writing 'vendor' OKAY [ 2.663s] >>>> > >>>> > Considering that the patch only moves buffer around to avoid a warning >>>> > message about misaligned buffers, let's keep the best performances. >>>> >>>> So what is the point of this warning? >>> >>> Well the warning does say something true that the cache operation is not >>> aligned. Better ask Simon as he's the one who changed the print from a >>> debug to warn_non_spl one: >>> bcc53bf0958 arm: Show cache warnings in U-Boot proper only >>> >>> BTW, in my case I couldn't see the misaligned messages, yet I saw the >>> performance hit described above. > > I also reproduce this problem on AM62x SK EVM. > > Before the revert: > Sending sparse 'super' 1/2 (768793 KB) OKAY [ 23.954s] > Writing 'super' OKAY [ 75.926s] > Sending sparse 'super' 2/2 (629819 KB) OKAY [ 19.641s] > Writing 'super' OKAY [ 62.849s] > Finished. Total time: 182.474s > > After the revert: > Sending sparse 'super' 1/2 (768793 KB) OKAY [ 23.895s] > Writing 'super' OKAY [ 12.961s] > Sending sparse 'super' 2/2 (629819 KB) OKAY [ 19.562s] > Writing 'super' OKAY [ 12.805s] > Finished. Total time: 69.327s > > And like Gary, I did not observe the misaligned messages. > > Did we come up with a solution for this performance regression? > > I will continue looking on my end but please let me know if you already > solved this. Answering to myself here. My attempt of solving this problem has been submitted here: https://lore.kernel.org/r/20230616-sparse-flash-fix-v1-1-6bafeacc5...@baylibre.com > > Thanks, > > Matijs > >> >> Maybe it is better to keep this as a Kconfig? Some arches may support >> unaligned access but others may not. I wonder if we have something like >> this already. >> >> --Seam
