Wireshark mailing list archives
Re: RFD: The Future of Memory Management in Wireshark
From: Sébastien Tandel <sebastien.tandel () gmail com>
Date: Wed, 24 Oct 2012 10:10:17 -0200
On Wed, Oct 24, 2012 at 1:10 AM, Guy Harris <guy () alum mit edu> wrote:
On Oct 18, 2012, at 6:01 PM, Evan Huus <eapache () gmail com> wrote:I have linked a tarball [2] containing the following files: - wmem_allocator.h - the definition of the allocator interface - wmem_allocator_glib.* - a simple implementation of the allocator interface backed by g_malloc and a singly-linked list.Presumably an implementation of the allocator could, instead of calling a lower-level memory allocator (malloc(), g_malloc(), etc.) for each allocation call, allocate larger chunks and parcel out memory from the larger chunks (as the current emem allocator does), if that ends up saving enough CPU, by making fewer allocate and free calls to the underlying memory allocator, so as to make it worth whatever wasted memory we have at the ends of chunks?
One step further, instead of mempools, I think wireshark could have great interest in implementing slabs (slab allocator<http://www.parrot.org/sites/www.parrot.org/files/vmem.pdf>). Slabs had initially been designed for kernel with several advantages over traditional allocators in terms of resources needed to allocate (CPU), (external / internal) fragmentation and also cache friendliness (most of the traditional allocators don't care). I've attached some slides about a high-level description of slab. Since then, another paper<http://www.parrot.org/sites/www.parrot.org/files/vmem.pdf>has been written showing some improvements and what it took to write a slab for user-space (libumem). There is another well-known exampel out there, called memcache, that implements its own version (and could be a good intial point for wireshark implementation, who knows? :)) Regards, Sebastien Tandel ___________________________________________________________________________
Sent via: Wireshark-dev mailing list <wireshark-dev () wireshark org> Archives: http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-request () wireshark org ?subject=unsubscribe
Attachment:
slab-allocator.pptx
Description:
___________________________________________________________________________ Sent via: Wireshark-dev mailing list <wireshark-dev () wireshark org> Archives: http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-request () wireshark org?subject=unsubscribe
Current thread:
- RFD: The Future of Memory Management in Wireshark Evan Huus (Oct 18)
- Re: RFD: The Future of Memory Management in Wireshark Guy Harris (Oct 23)
- Re: RFD: The Future of Memory Management in Wireshark Evan Huus (Oct 23)
- Re: RFD: The Future of Memory Management in Wireshark Sébastien Tandel (Oct 24)
- Re: RFD: The Future of Memory Management in Wireshark Evan Huus (Oct 24)
- Re: RFD: The Future of Memory Management in Wireshark Sébastien Tandel (Oct 26)
- Re: RFD: The Future of Memory Management in Wireshark Evan Huus (Oct 26)
- Re: RFD: The Future of Memory Management in Wireshark Graham Bloice (Oct 26)
- Re: RFD: The Future of Memory Management in Wireshark Evan Huus (Oct 26)
- Re: RFD: The Future of Memory Management in Wireshark Sébastien Tandel (Oct 26)
- Re: RFD: The Future of Memory Management in Wireshark Evan Huus (Oct 26)
- Re: RFD: The Future of Memory Management in Wireshark Sébastien Tandel (Oct 26)
- Re: RFD: The Future of Memory Management in Wireshark Guy Harris (Oct 23)
- Re: RFD: The Future of Memory Management in Wireshark Evan Huus (Oct 25)