On Wed, Oct 14, 2009 at 12:25 PM, Sasha Khapyorsky <[email protected]> wrote: > On 11:52 Wed 14 Oct , Hal Rosenstock wrote: >> >> Heap memory consumption by the unicast and multicast routing tables can be >> reduced. >> >> This patch is analagous to the previous patch doing this for the unicast >> routing tables (LFTs). >> >> Using valgrind --tool=massif (for heap profiling), there are couple of place >> ->38.75% (11,206,656B) 0x43267E: osm_switch_new (osm_switch.c:134) >> ->12.89% (3,728,256B) 0x40F8C9: osm_mcast_tbl_init (osm_mcast_tbl.c:96) >> >> osm_mcast_tbl_init (osm_mcast_tbl.c:96): >> p_tbl->p_mask_tbl = malloc(p_tbl->num_entries * >> (IB_MCAST_POSITION_MAX + >> 1) * IB_MCAST_MASK_SIZE / 8); >> >> num_entries above is set based on the switch's MulticastFDBCap >> (indicated in it's SM class SwitchInfo attribute). >> >> MFTs are only be increased in size and are never reduced in size. If a >> realloc >> for MFT fails, it is treated as a fatal error and OpenSM is exited. >> >> Signed-off-by: Hal Rosenstock <[email protected]> >> --- >> Changes since v1: >> MFT allocation based on actual MLID requests > > I meant not just this. > > When first LFT allocation size reducing patch was posted we discussed > and agreed that it is better to allocate tables using already known and > needed sizes before routing calculation cycle start (as part of the > preparation to this) and not at any table access attempt. Any reason why > should this be different with MFTs?
Seems to me that the equivalent (to LFT) is to invoke the table (re)allocation from osm_mcast_mgr_process/process_mgroups. Is that what you mean ? -- Hal > Sasha <snip...> -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
