On Tue, Apr 05, 2011 at 10:37:37AM +0100, Mindaugas Rasiukevicius wrote: > It could be DTrace facility or some __builtin_return_address tracking > to have some means e.g. to identify memory leaks when kmem(9) is used. > > I am not convinced about statistics point. For intensive allocations, > constant-sized pool_cache(9) should/would be used, where it already > gathers statistics.
no, that's not the same thing. It doesn't tell you where the memory did go, which is what KMEMSTATS does. > If there is some particular need for statistics, I compile all my kernels (even on production system) with KMEMSTATS. So it looks like there's a need :) > one can always collect it at the caller's level. so you end up with N different statistic systems, and some memory allocation are below the radar, because the caller didn't bother to collect stats. > Therefore, I do not > see the need to invade allocator's API for that. > > -- > Mindaugas -- Manuel Bouyer <[email protected]> NetBSD: 26 ans d'experience feront toujours la difference --
