On Mon, 18 Mar 2019, Robert Mustacchi wrote:
Now, the reason that it's much worse is due to the implementation of memalign() in libumem. What happens is that it tries to see if the alignment is satisfied by malloc's default alignment in umem and if not, falls back to using the vmem interfaces. This is pretty unfortunate, as it's pretty clear that in a lot of cases it'd be much better to just use a larger allocation and align inside of it ourselves, much like I suspect your own wrapper is doing. I think improving the memalign performance here for the common cases that fit within our normal umem cache size would be helpful.
My wrapper is indeed allocating more data than required. It returns a pointer to the next aligned address and stores the actual allocated address just under that point. An unfortunate thing about this approach is that the function which frees the data needs to know about it and so I use a different function to free the allocation. Another unfortunate thing is that if malloc() happens to return an address with the desired alignment (which some systems might always do!), it is still necessary to waste memory since there is no reasonable way for the function which frees the allocation to know about how the buffer was allocated.
Bob -- Bob Friesenhahn [email protected], http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer, http://www.GraphicsMagick.org/ Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt ------------------------------------------ illumos: illumos-discuss Permalink: https://illumos.topicbox.com/groups/discuss/T30dd2eceb8a069b3-Ma5bcd8197f44d9fc94d5c0a4 Delivery options: https://illumos.topicbox.com/groups/discuss/subscription
