On Fri, 4 Apr 2008 12:06:23 -0400
Mathieu Desnoyers <compudj@krystal.dyndns.org> wrote:

quoted text
> I like this :) But could we trace event sooner if we did not depend on
> vmalloc to allocate the buffers ?
> 
> I am thinking of receiving a kernel parameter that would reserve a
> buffer in the linear kernel mapping (kmalloc ?), or to compile-in a
> static buffer, which could be used by relay instead of the vmalloc'd
> buffer. That would permit to trace the memory allocator and some other
> very early stuff. Basically, relay would have it's "memory pool" to
> manage and would do its allocations from this fixed buffer. No free
> would be required.
> 
> Mathieu

Sure. I'm doing this as part of my GSoC application (well, I haven't
been accepted yet). I had also proposed this to Pekka Enberg, my
mentor, but he was reluctant to hack the relay code more invasively. Now
that you agree with this, I'll work on it.

kmalloc() doesn't work before kmem_cache_init() and relay code uses
kmalloc(), not vmalloc(), IIRC.

I would go another way. Have the relay client call __get_free_pages()
or similar function, allocate the buffer and pass it on to a variant of
relay_open(), let's name it relay_early_open(). __get_free_pages() can
be used before kmem_cache_init() as far as I know. No free is required,
since early tracing code implies it's built into the kernel and not as
a module. What do you say?

Will you merge this or wait until I finish the very early tracing stuff?

Cheers,
Eduard
--
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/