On Wed, Apr 06, 2011 at 04:39:04PM +0100, Mindaugas Rasiukevicius wrote: > Manuel Bouyer <[email protected]> wrote: > > 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. > > It is not, but I argue that mechanism for catching memory leaks is more > important point.
KMEMSTATS is a good starting point actually. with plain kmem, you see that the kernel is eating memory, but you can't say much more. > > > > 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. > > No, I do not see the need to collect statistics about every allocation, > e.g. load of temporary buffer, string, whatever allocations/frees. > > It can rather be information about subsystem behaviour, which can include > statistics of memory usage, say, in network stack. That should not end up > in many different statistics systems. There are many cases where number > of some structures is already tracked as part of other mechanisms, therefore > allocations. For intensive cases, I'll repeat again - we use pool_cache(9), > which collects statistics. but I guess pool_cache will only have a generic name to display, and no information about where the memory did go ... -- Manuel Bouyer <[email protected]> NetBSD: 26 ans d'experience feront toujours la difference --
