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

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

On 04/03/11 14:52, Manuel Bouyer wrote:
> On Sun, Apr 03, 2011 at 02:36:37PM +0200, Lars Heidieker wrote:
>> On 04/03/11 01:36, Matthew Mondor wrote:
>>> On Sat, 2 Apr 2011 11:49:14 +0200
>>> Martin Husemann <martin%duskware.de@localhost> wrote:
>>>
>>>> On Sat, Apr 02, 2011 at 11:30:16AM +0200, Manuel Bouyer wrote:
>>>>> AFAIK dtrace doesn't work on non-modular kernels ...
>>>> Nor on most of our archs, and AFAICT there is not even a document
>>>> describing the (maybe nontrivial amount of) work needed to make it
>>>> work there.
>>> I don't think that we should leave the tracking for a hypothetical
>>> future; it'd be better if the interface, or implementation, allowed to
>>> do such tracking....
>>
>> Just an Idea, how about giving the kmem allocator a pool like logging...
>
> or malloc(9)-like :)
>
:-) The trouble is large parts of the kernel are migrated to kmem
already and having too interfaces and two allocators is something that
needs cleanup. The malloc-type statistics would need a major overhaul
if they are the way to go, what I doubt, as the essentially make
malloc single threaded even if it is backed by kmem caches with
cpu-local caches.