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

[Mindaugas Rasiukevicius <rmind%netbsd.org@localhost>]

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.

> > 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.

-- 
Mindaugas