sdkconfig system settings

DrMickeyLauer
Posts: 168
Joined: Sun May 22, 2022 2:42 pm

sdkconfig system settings

Postby DrMickeyLauer » Sat Mar 02, 2024 12:37 pm

Of all the things in the ESP32 universe, the sdkconfig is scaring me the most. There are so many things to fiddle with and I'm afraid to change options since it's not always clear what they are doing.

I now have enabled CONFIG_ESPTOOLPY_FLASHMODE_QIO=y for my project which gives an enormous performance boost. Will this produce any stability issues? I'm using ESP32-S3-WROOM-1-N16R8 modules.

Another scary part is the cache configuration. Is there any benefit leaving it into default configuration or can I just bump the DATA_CACHE to 64KB and the CACHE_LINE to 64b?

MicroController
Posts: 1701
Joined: Mon Oct 17, 2022 7:38 pm
Location: Europe, Germany

Re: sdkconfig system settings

Postby MicroController » Sat Mar 02, 2024 7:58 pm

DrMickeyLauer wrote:
Sat Mar 02, 2024 12:37 pm
I now have enabled CONFIG_ESPTOOLPY_FLASHMODE_QIO=y for my project which gives an enormous performance boost. Will this produce any stability issues?
No stability problems here. Either the flash supports QIO or it doesn't. If it doesn't, you'll immediately find out.
Another scary part is the cache configuration. Is there any benefit leaving it into default configuration or can I just bump the DATA_CACHE to 64KB and the CACHE_LINE to 64b?
Smaller cache -> more available heap. If you have enough RAM to spare, go ahead and ramp up the cache size; using some RAM for the cache is better than not using that RAM at all.
Which cache configuration is 'best' depends on the behavior of the application. AFAIK, the MMU transfers data in blocks of one cache line to/from external memory. Every transfer incurs some overhead, so you want to minimize the number of transfers needed. OTOH, loading data into the cache that will end up not being used is also wasteful. If you'd often only need to access e.g. one byte from PSRAM, loading 64 bytes each time may be slower than loading just 32 bytes; if you'd often access data that spans more than one 32 byte cache line, 64 byte lines may be faster than 32.
So it all depends, and either way may be beneficial or detrimental to your application's overall performance.
If your application, or specific crucial functionality, is fast enough, I'd see no need to change the cache config.

DrMickeyLauer
Posts: 168
Joined: Sun May 22, 2022 2:42 pm

Re: sdkconfig system settings

Postby DrMickeyLauer » Sun Mar 03, 2024 11:19 am

Thanks!
MicroController wrote:
Sat Mar 02, 2024 7:58 pm
Smaller cache -> more available heap. If you have enough RAM to spare, go ahead and ramp up the cache size; using some RAM for the cache is better than not using that RAM at all.
Which cache configuration is 'best' depends on the behavior of the application. AFAIK, the MMU transfers data in blocks of one cache line to/from external memory. Every transfer incurs some overhead, so you want to minimize the number of transfers needed. OTOH, loading data into the cache that will end up not being used is also wasteful. If you'd often only need to access e.g. one byte from PSRAM, loading 64 bytes each time may be slower than loading just 32 bytes; if you'd often access data that spans more than one 32 byte cache line, 64 byte lines may be faster than 32.
So it all depends, and either way may be beneficial or detrimental to your application's overall performance.
If your application, or specific crucial functionality, is fast enough, I'd see no need to change the cache config.
Makes sense, but is there any way to instrument this to make an informed decision based on letting my app run for a while with typical workloads?

MicroController
Posts: 1701
Joined: Mon Oct 17, 2022 7:38 pm
Location: Europe, Germany

Re: sdkconfig system settings

Postby MicroController » Mon Mar 04, 2024 3:59 pm

I guess the only promising approach is to simply time critical pieces of code and see if/how different cache settings affect the performance there, while also checking if/how much other sections may be negatively affected.

(There are hardware cache hit/miss counters in (some?) ESP's, but I'd say any numbers from those give a pretty indirect indication at best as to the actual performance of your (critical) code.)

By the way: Having gcc optimize for "speed" ("O3") may actually degrade performance vs. "Os" because gcc doesn't take into account the performance penalty incurred by larger code size. (Especially when gcc inlines, i.e. duplicates, a function's code multiple times cache misses are likely to increase. An __attribute__((noinline)) here and there can help mitigate this effect when compiling with "O3".)

charlie choi
Posts: 1
Joined: Thu Jul 07, 2022 12:03 am

Re: sdkconfig system settings

Postby charlie choi » Wed Aug 28, 2024 11:57 pm

MicroController wrote:
Mon Mar 04, 2024 3:59 pm
I guess the only promising approach is to simply time critical pieces of code and see if/how different cache settings affect the performance there, while also checking if/how much other sections may be negatively affected.

(There are hardware cache hit/miss counters in (some?) ESP's, but I'd say any numbers from those give a pretty indirect indication at best as to the actual performance of your (critical) code.)

By the way: Having gcc optimize for "speed" ("O3") may actually degrade performance vs. "Os" because gcc doesn't take into account the performance penalty incurred by larger code size. (Especially when gcc inlines, i.e. duplicates, a function's code multiple times cache misses are likely to increase. An __attribute__((noinline)) here and there can help mitigate this effect when compiling with "O3".)
//////////////////////////////////////////////////////////////////////////////////////////////
Hi, I am also a beginner using the same module. So SDKCONFIG is important but difficult. Could you share your SDKCONFIG file? It will be a great help to me.

Who is online

Users browsing this forum: Bing [Bot] and 108 guests