On 11 Feb 2015, at 10:58, Arran Cudbard-Bell <a.cudbardb@freeradius.org> wrote:
On 11 Feb 2015, at 10:35, Phil Mayers <p.mayers@IMPERIAL.AC.UK> wrote:
On 10/02/15 22:05, Alan DeKok wrote:
After some discussion, I moved the REQUESTs to using a talloc pool. i.e. it allocates a 32K chunk of memory for reach request, and then allocates REQUEST, RADIUS_PACKET, VALUE_PAIR, etc. within that. If the pool runs out of memory, talloc() will fall back to using malloc. So there’s no downside to this. We’ve made a few other minor changes, too.
Preliminary performance tests show a 35% decrease in time (clock cycles, via valgrind) to process the default configuration, with one user:
Cool. I was going to suggest a talloc_pool() for REQUEST's a while back but never got round to doing any measurement.
I guess the pool size could be a global but it's almost certainly unnecessary - most requests won't be around for long enough for it to matter.
It'd be a bit of a pain to keep track TBH. You can use a single pool because of thread safety issues, so you'd need to keep track of the number of requests allocated.
*can't use. As you already know, as you were the one who discovered that particular issue :) Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS development team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2