From: Mathieu Desnoyers <compudj@krystal.dyndns.org>
To: Eduard - Gabriel Munteanu <eduard.munteanu@linux360.ro>
Cc: LKML <linux-kernel@vger.kernel.org>,
Pekka Enberg <penberg@cs.helsinki.fi>,
Tom Zanussi <zanussi@us.ibm.com>
Subject: Re: [PATCH] relay: add buffer-only functionality, allowing for early kernel tracing
Date: Fri, 4 Apr 2008 12:40:22 -0400 [thread overview]
Message-ID: <20080404164022.GA1762@Krystal> (raw)
In-Reply-To: <20080404191943.2d708cbf@linux360.ro>
* Eduard - Gabriel Munteanu (eduard.munteanu@linux360.ro) wrote:
> On Fri, 4 Apr 2008 12:06:23 -0400
> Mathieu Desnoyers <compudj@krystal.dyndns.org> wrote:
>
> > 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.
>
It currently uses both :
It uses alloc_page and vmap to allocate the buffers and it uses
kzalloc/kmalloc to allocate the relay structures.
> 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?
>
Then I guess we would depend on page_alloc_init(). It's not that bad,
but I guess the question is : do we prefer to let users specify the
buffer size to reserve for tracing on the kernel command line (that
would require __get_free_pages()) or do we compile-in a static buffer
size, which can be specified in the kernel configuration. I think
providing both could be an option : flexibility _and_ *very* early
tracing.
So making this relay interface flexible enough to receive a buffer
either reserved by __get_free_pages() or a static buffer seems like a
good compromise. It would also have to receive the buffer size from the
caller.
> Will you merge this or wait until I finish the very early tracing stuff?
>
As far as I am concerned, I can only merge this in the LTTng project to
try it. I've added Tom Zanussi, the author of relay, who might have some
ideas to share with us. I would wait until we have a more precise idea
of the API before I modify LTTng to start using it.
Regards,
Mathieu
> Cheers,
> Eduard
>
--
Mathieu Desnoyers
Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68
next prev parent reply other threads:[~2008-04-04 16:45 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-04-04 15:33 [PATCH] relay: add buffer-only functionality, allowing for early kernel tracing Eduard - Gabriel Munteanu
2008-04-04 16:06 ` Mathieu Desnoyers
2008-04-04 16:19 ` Eduard - Gabriel Munteanu
2008-04-04 16:40 ` Mathieu Desnoyers [this message]
2008-04-04 17:06 ` Eduard - Gabriel Munteanu
2008-04-06 1:27 ` Eduard - Gabriel Munteanu
2008-04-04 16:08 ` Randy Dunlap
2008-04-04 16:28 ` Eduard - Gabriel Munteanu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20080404164022.GA1762@Krystal \
--to=compudj@krystal.dyndns.org \
--cc=eduard.munteanu@linux360.ro \
--cc=linux-kernel@vger.kernel.org \
--cc=penberg@cs.helsinki.fi \
--cc=zanussi@us.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.