Re: extent-patch and overview of what is supposed to follow

[Manuel Bouyer <bouyer%antioche.eu.org@localhost>]

On Wed, Apr 06, 2011 at 04:39:04PM +0100, Mindaugas Rasiukevicius wrote:
> Manuel Bouyer <bouyer%antioche.eu.org@localhost> 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 <bouyer%antioche.eu.org@localhost>
     NetBSD: 26 ans d'experience feront toujours la difference
--