I'm running 100 xorp instances on a dual-quad core system (E5530, 2.4Ghz) I let them run a while, which tends to hide the xrl stuff that is mainly a startup cost.
This is my patched tree, by the way. FEA is the top entry on the entire OS (but, there are 100 FEAs running, so that's not un-expected) At least in my code tree, the get_ready_priority is a couple of for loops..and could probably be optimized, to better ignore fds that are not in use. samples % image name app name symbol name ------------------------------------------------------------------------------- 22 0.0766 xorp_fea xorp_fea EventLoop::do_work(bool) 28687 99.9234 xorp_fea xorp_fea SelectorList::wait_and_dispatch(TimeVal& ) 27759 6.5897 xorp_fea xorp_fea SelectorList::get_ready_priority(bool) 27759 99.6196 xorp_fea xorp_fea SelectorList::get_ready_priority(bool) [ self] 54 0.1938 xorp_fea xorp_fea SelectorList::do_select(timeval*, bool) 52 0.1866 xorp_fea xorp_fea std::vector<SelectorList::Node, std::all ocator<SelectorList::Node> >::operator[](unsigned long) Nothing else really stands out, except that we are probably creating and deleting a lot of strings (or something else with an underlying vector in it), which calls memset. I can't tell from oprofile what the call chain for the memset usage is though, will look for other ways to get at that... Thanks, Ben -- Ben Greear <[email protected]> Candela Technologies Inc http://www.candelatech.com _______________________________________________ Xorp-hackers mailing list [email protected] http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers
