3 ms·

Needing memory doesn't have to mean allocating memory over and over. Memory allocation is expensive. If someone is doing that reusing memory is going to be by f

Needing memory doesn't have to mean allocating memory over and over. Memory allocation is expensive. If someone is doing that reusing memory is going to be by far the best optimization.

fulafel 7mo ago
Well, allocating and freeing according to need is reusing. Modern TCP perf is not bottlenecked by that. There's pools of recycled buffers that grow and shrink according to load etc.
- CyberDildonics 7mo ago
  Well, allocating and freeing according to need is reusing That's a twisted definition. It seems like you're playing around with terms, but allocating memory from a heap allocator is obviously what people are talking about with "dynamic memory allocation". Reusing memory that has already been grabbed from an allocator is not reallocating memory. If you have a buffer and it works you don't need to do anything to reuse it. Modern TCP perf is not bottlenecked by that. There's pools of recycled buffers that grow and shrink according to load etc. If anything is allocating memory from the heap in a hot loop it will be a bottleneck. Reusing buffers is not allocating memory dynamically.
  - fulafel 7mo ago
    Sorry but there's shades of gray between heap allocation and TCP specific free lists in TCP impls. It's not a black and white free list vs malloc API situation. For example in Linux there are middle level abstraction layers in play as follows: For the payload there's a per socket runway of memory to be used for example (sk_page_frag). Then, if there's a miss on that pool, instead of calling the malloc (or kmalloc in the case of Linux) API, it invokes the page allocator to get a bunch of VM pages in one go, which is again more efficient than using the generic heap API. The page allocation API will recycle recently freed large clusters of memory, and the page alloc is again backed by a CPU-local per cpu pageset etc. It's turtles all the way down. For the metadata (sk_head) there's separate skbuff_head_cache that facilitates recycling for the generic socket metadata, which is again not a TCP specific thing but lower level than generic heap allocator, somewhere between a TCP free list and malloc in the tower of abstractions.
    - CyberDildonics 7mo ago
      It's not a black and white free list vs malloc API situation. It is in the sense that if finding a buffer that's the right length was just as slow as malloc (and free) then you would just use malloc. Not only that but malloc is shared with the entire program and can do a lot of locking. On top of that there is the memory locality of using the same heap as the rest of the program. If you just make your own heap there is a big difference between using the system allocator over and over and reusing local memory buffers for a specific thread and purpose. What you're describing here the same thing, avoiding the global heap allocator.

Needing memory doesn't have to mean allocating memory over and over. Memory allocation is expensive. If someone is doing that reusing memory is going to be by far the best optimization.

fulafel 7mo ago

Well, allocating and freeing according to need is reusing. Modern TCP perf is not bottlenecked by that. There's pools of recycled buffers that grow and shrink according to load etc.

CyberDildonics 7mo ago
Well, allocating and freeing according to need is reusing That's a twisted definition. It seems like you're playing around with terms, but allocating memory from a heap allocator is obviously what people are talking about with "dynamic memory allocation". Reusing memory that has already been grabbed from an allocator is not reallocating memory. If you have a buffer and it works you don't need to do anything to reuse it. Modern TCP perf is not bottlenecked by that. There's pools of recycled buffers that grow and shrink according to load etc. If anything is allocating memory from the heap in a hot loop it will be a bottleneck. Reusing buffers is not allocating memory dynamically.
- fulafel 7mo ago
  Sorry but there's shades of gray between heap allocation and TCP specific free lists in TCP impls. It's not a black and white free list vs malloc API situation. For example in Linux there are middle level abstraction layers in play as follows: For the payload there's a per socket runway of memory to be used for example (sk_page_frag). Then, if there's a miss on that pool, instead of calling the malloc (or kmalloc in the case of Linux) API, it invokes the page allocator to get a bunch of VM pages in one go, which is again more efficient than using the generic heap API. The page allocation API will recycle recently freed large clusters of memory, and the page alloc is again backed by a CPU-local per cpu pageset etc. It's turtles all the way down. For the metadata (sk_head) there's separate skbuff_head_cache that facilitates recycling for the generic socket metadata, which is again not a TCP specific thing but lower level than generic heap allocator, somewhere between a TCP free list and malloc in the tower of abstractions.
  - CyberDildonics 7mo ago
    It's not a black and white free list vs malloc API situation. It is in the sense that if finding a buffer that's the right length was just as slow as malloc (and free) then you would just use malloc. Not only that but malloc is shared with the entire program and can do a lot of locking. On top of that there is the memory locality of using the same heap as the rest of the program. If you just make your own heap there is a big difference between using the system allocator over and over and reusing local memory buffers for a specific thread and purpose. What you're describing here the same thing, avoiding the global heap allocator.