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

[Lars Heidieker <lars%heidieker.de@localhost>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 04/06/11 17:39, 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.
>
>>> 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.
>

I don't see the need either, I can understand it from debugging
purposes, but the stats malloc collects don't show who exactly
allocated but only the subsystem and that information is somewhat
manual with passing types to malloc and free, some real tracing with
dtrace eg seems to be more appropriate too me for the job.

- -- 
- ------------------------------------

Mystische Erklärungen:
Die mystischen Erklärungen gelten für tief;
die Wahrheit ist, dass sie noch nicht einmal oberflächlich sind.

   -- Friedrich Nietzsche
   [ Die Fröhliche Wissenschaft Buch 3, 126 ]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk2cjFwACgkQcxuYqjT7GRanPwCgitI868EJupuUVelB4t9iOEMG
spAAmwRHMbgqisaRScJ4XE14RAfYZSlM
=So1g
-----END PGP SIGNATURE-----