linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Eduard - Gabriel Munteanu <eduard.munteanu@linux360.ro>
To: Mathieu Desnoyers <compudj@krystal.dyndns.org>
Cc: LKML <linux-kernel@vger.kernel.org>,
	Pekka Enberg <penberg@cs.helsinki.fi>
Subject: Re: [PATCH] relay: add buffer-only functionality, allowing for early kernel tracing
Date: Fri, 4 Apr 2008 19:19:43 +0300	[thread overview]
Message-ID: <20080404191943.2d708cbf@linux360.ro> (raw)
In-Reply-To: <20080404160623.GC32126@Krystal>

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.

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

  reply	other threads:[~2008-04-04 16:20 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 [this message]
2008-04-04 16:40     ` Mathieu Desnoyers
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=20080404191943.2d708cbf@linux360.ro \
    --to=eduard.munteanu@linux360.ro \
    --cc=compudj@krystal.dyndns.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=penberg@cs.helsinki.fi \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).