Hi all, please refer me to another discussion group if it's more fit there (like zones or networking).
The fanout runtime for locating TCP bind entries behaves linearly with respect to the numbers of zones - not a good thing, especially since one of the strong points for zones are the low performance overhead. The arrays tcp_bind_fanout and tcp_acceptor_fanout and their fanout makros don't orgranize their data by zone. If one runs a system with 100 active zones, the average runtime to lookup the respective data entry will be many-fold of that of a system without zones (assuming all systems expose comparable network behaviour and the connection establishment rate is rather high, and... - and yes, you may slap me across the head with a statistics book). The only reasonable scenario for this to become a bottleneck would be in such a highly zoned system, with each zone providing the same network service, if all systems were webservers (or just happened to operate on ports that fell into the same fanout entry - ie: (portA-portB)%512==0). I could work out an alternative implementation, but would like to discuss alternatives beforehand - these two are first ideas: - a top-level fanout mechanism for zones - inserting "zone divider" nodes into the linked lists, providing quick jumps within the list to the corresponding "list section" (which contains all entries for a given zone) I realize that this may not be the worst scalability issue, it's still one that can easily be resolved. jp This message posted from opensolaris.org _______________________________________________ perf-discuss mailing list perf-discuss@opensolaris.org
