[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: extent-patch and overview of what is supposed to follow
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
> > > 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
Main Index |
Thread Index |