On Tue, Apr 14, 2015 at 09:44:10AM -0400, Russell Bryant wrote: > The poll_block() function already has some state in thread-specific > storage that's used as a registry for all of the fds to poll() on the > next time poll_block() gets called. poll_block() was calling > malloc() and free() every time it was called to create the pollfd and > wevents arrays needed to pass to poll(). We can optimize this a bit > by caching the allocation on the existing thread-specific storage and > just reallocating it to a larger size if necessary. > > Signed-off-by: Russell Bryant <rbry...@redhat.com> > --- > lib/poll-loop.c | 40 ++++++++++++++++++++++++++++------------ > 1 file changed, 28 insertions(+), 12 deletions(-) > > > v1->v2: > - Actually free the two allocations in free_poll_loop(). Oops. > v2->v3: > - Simplify call to realloc() since it can take NULL as suggested by > Jarno Rajahalme.
I've thought about doing this several times myself, but I never bothered because it never showed up in profiles. I think that's because small mallocs, for small numbers of fds, are cheap and large mallocs will only happen for large numbers of fds, in which case the cost of the large malloc for N fds is overtaken by the N individual allocations of "struct poll_node"s. That could be done through some kind of pool allocator, but again it doesn't show up in profiles. The whole thing suggests to me that it's not a fruitful place to optimize, so that I'd rather just keep the code simple. The other place I always think about optimizing here is to skip most of the code in poll_block() entirely if "timeout_when" is a time that's already past. I've tried that optimization multiple times, in fact, but it never makes a measurable difference so I don't think I've ever posted it. Food for thought. _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
