No more MIN_FREE_CHUNK_SIZE limitation (#1555)

* Do not use MIN_FREE_CHUNK_SIZE limitation - the provider's alignment will do the trick!

* Do not leave empty free chunks

commons/zenoh-shm/src/api/protocol_implementations/posix/posix_shm_provider_backend.rs

@@ -36,13 +36,6 @@ use crate::api::{
     },
 };
 
-// TODO: MIN_FREE_CHUNK_SIZE limitation is made to reduce memory fragmentation and lower
-// the CPU time needed to defragment() - that's reasonable, and there is additional thing here:
-// our SHM\zerocopy functionality outperforms common buffer transmission only starting from 1K
-// buffer size. In other words, there should be some minimal size threshold reasonable to use with
-// SHM - and it would be good to synchronize this threshold with MIN_FREE_CHUNK_SIZE limitation!
-const MIN_FREE_CHUNK_SIZE: usize = 1_024;
-
 #[derive(Eq, Copy, Clone, Debug)]
 struct Chunk {
     offset: ChunkID,
@@ -181,7 +174,8 @@ impl ShmProviderBackend for PosixShmProviderBackend {
             Some(mut chunk) if chunk.size >= required_len => {
                 // NOTE: don't loose any chunks here, as it will lead to memory leak
                 tracing::trace!("Allocator selected Chunk ({:?})", &chunk);
-                if chunk.size.get() - required_len.get() >= MIN_FREE_CHUNK_SIZE {
+
+                if chunk.size > required_len {
                     let free_chunk = Chunk {
                         offset: chunk.offset + required_len.get() as ChunkID,
                         // SAFETY: this is safe because we always operate on a leftover, which is checked above!
@@ -193,6 +187,7 @@ impl ShmProviderBackend for PosixShmProviderBackend {
                     guard.push(free_chunk);
                     chunk.size = required_len;
                 }
+
                 self.available
                     .fetch_sub(chunk.size.get(), Ordering::Relaxed);