Fslock optimize

[crafcat7]

Summary

1. Add lib_get_pathbuffer / lib_put_pathbuffer instead of temporary variable.
2. Reduce stack size. Getting the tmp buffer through the lib_get_pathbuffer function reduces the declaration of temporary variables
3. Fix an unsynchronized lock acquisition by closelk in multi-threaded scenarios. Ensure atomic behavior when acquiring lock status.
4. Optimized additional performance overhead due to closelk in the close phase (even if the fd doesn't use fslock)
   Optimizing performance:
   Before: Time taken to close the file: 33984 nsec
   After: Time taken to close the file: 23744 nsec
   Improvement of about 10 msec

Impact

Optimizing fslock

Testing

Local test pass

[PetervdPerk-NXP]

You're trading stack usage for heap fragmentation.
I disagree with this approach because once your heap is to fragmented malloc would simply fail and your system most likely crashes.
if you really want it I propose you make an optional kconfig symbol called i.e. dynamic path allocation

[crafcat7]

You're trading stack usage for heap fragmentation. I disagree with this approach because once your heap is to fragmented malloc would simply fail and your system most likely crashes. if you really want it I propose you make an optional kconfig symbol called i.e. dynamic path allocation

lib_get_pathbuffer will initially request an address from a global stack, just like we use temporary variables, which will not cause memory fragmentation. Unless the current usage peak exceeds the available buffer, it will request from the heap.

I think the fragmentation problem can be tuned with CONFIG_LIBC_MAX_PATHBUFFER, which can reduce/avoid malloc from heap

[guohao15]

You're trading stack usage for heap fragmentation. I disagree with this approach because once your heap is to fragmented malloc would simply fail and your system most likely crashes. if you really want it I propose you make an optional kconfig symbol called i.e. dynamic path allocation

We can use LIBC_MAX_PATHBUFFER Kconfig to optimise the useasge of this buffer, reduce the chance that system alloc memory form heap .

[xiaoxiang781216]

You're trading stack usage for heap fragmentation.

the allocation doesn't happen if the concurrent usage doesn't exceed CONFIG_LIBC_MAX_PATHBUFFER.

I disagree with this approach because once your heap is to fragmented malloc would simply fail and your system most likely crashes. if you really want it I propose you make an optional kconfig symbol called i.e. dynamic path allocation

if you want, we can add an option to skip the allocation and return NULL directly if the usage exceeds CONFIG_LIBC_MAX_PATHBUFFER.

[PetervdPerk-NXP]

if you want, we can add an option to skip the allocation and return NULL directly if the usage exceeds CONFIG_LIBC_MAX_PATHBUFFER.

Yeah that sounds more logical to me. I don't like the idea of hidden malloc's.

[xiaoxiang781216]

if you want, we can add an option to skip the allocation and return NULL directly if the usage exceeds CONFIG_LIBC_MAX_PATHBUFFER.

Yeah that sounds more logical to me. I don't like the idea of hidden malloc's.

OK, @crafcat7 will create a new patch to forbid the allocation.

[crafcat7]

if you want, we can add an option to skip the allocation and return NULL directly if the usage exceeds CONFIG_LIBC_MAX_PATHBUFFER.

Yeah that sounds more logical to me. I don't like the idea of hidden malloc's.

OK, @crafcat7 will create a new patch to forbid the allocation.

Done

[xiaoxiang781216]

@crafcat7 please fix the conflict.

[crafcat7]

@crafcat7 please fix the conflict.

Done

[PetervdPerk-NXP]

So this should either be 0 or only be set if fs_lock is enabled.
Otherwise we're wasting 512 bytes of RAM.

[xiaoxiang781216]

actually, we don't need do this optimization manually, the linker is enough smart to remove the unused code and data from the final image automatically if nobody calls lib_[get|put]_pathbuffer.