From: Tom Zanussi <tom.zanussi@linux.intel.com>
To: Alexei Starovoitov <ast@plumgrid.com>
Cc: Steven Rostedt <rostedt@goodmis.org>,
Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>,
Namhyung Kim <namhyung@kernel.org>,
Andi Kleen <andi@firstfloor.org>,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 07/15] mm: Add ___GFP_NOTRACE
Date: Mon, 02 Mar 2015 12:03:26 -0600 [thread overview]
Message-ID: <1425319406.20819.9.camel@picadillo> (raw)
In-Reply-To: <CAMEtUuzkEgMDWDqdqyzd4ZMGs96CzY1TYJkaXenW1vZ4DsC5Qw@mail.gmail.com>
On Mon, 2015-03-02 at 09:58 -0800, Alexei Starovoitov wrote:
> On Mon, Mar 2, 2015 at 8:46 AM, Tom Zanussi <tom.zanussi@linux.intel.com> wrote:
> > On Mon, 2015-03-02 at 11:37 -0500, Steven Rostedt wrote:
> >> On Mon, 2 Mar 2015 10:01:00 -0600
> >> Tom Zanussi <tom.zanussi@linux.intel.com> wrote:
> >>
> >> > Add a gfp flag that allows kmalloc() et al to be used in tracing
> >> > functions.
> >> >
> >> > The problem with using kmalloc for tracing is that the tracing
> >> > subsystem should be able to trace kmalloc itself, which it can't do
> >> > directly because of paths like kmalloc()->trace_kmalloc()->kmalloc()
> >> > or kmalloc()->trace_mm_page_alloc()->kmalloc().
> >>
> >> This part I don't like at all. Why can't the memory be preallocated
> >> when the hist is created (the echo 'hist:...')?
> >>
> >
> > Yeah, I didn't like it either. My original version did exactly what you
> > suggest and preallocated an array of entries to 'allocate' from in order
> > to avoid the problem.
> >
> > But I wanted to attempt to use the bpf_map directly, which already uses
> > kmalloc internally. My fallback in case this wouldn't fly, which it
> > obviously won't, would be to add an option to have the bpf_map code
> > preallocate a maximum number of entries or pass in a client-owned array
> > for the purpose. I'll do that if I don't hear any better ideas..
>
> Tom, I'm still reading through the patch set.
> Quick comment for the above.
> Currently there are two map types: array and hash.
> array type is pre-allocating all memory at map creation time.
> hash is allocating on demand.
OK, so would it make sense to do the same for the hash type, or at least
add an option that does that?
Tom
next prev parent reply other threads:[~2015-03-02 18:03 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-03-02 16:00 [PATCH v2 00/15] tracing: 'hist' triggers Tom Zanussi
2015-03-02 16:00 ` [PATCH 01/15] tracing: Make ftrace_event_field checking functions available Tom Zanussi
2015-03-02 16:00 ` [PATCH 02/15] tracing: Add event record param to trigger_ops.func() Tom Zanussi
2015-03-02 16:00 ` [PATCH 03/15] tracing: Add get_syscall_name() Tom Zanussi
2015-03-02 16:00 ` [PATCH 04/15] bpf: Export bpf map functionality as trace_map_* Tom Zanussi
2015-03-02 16:00 ` [PATCH 05/15] bpf: Export a map-clearing function Tom Zanussi
2015-03-02 16:00 ` [PATCH 06/15] bpf: Add tracing_map client ops Tom Zanussi
2015-03-02 16:01 ` [PATCH 07/15] mm: Add ___GFP_NOTRACE Tom Zanussi
2015-03-02 16:37 ` Steven Rostedt
2015-03-02 16:46 ` Tom Zanussi
2015-03-02 17:58 ` Alexei Starovoitov
2015-03-02 18:03 ` Tom Zanussi [this message]
2015-03-02 18:12 ` Alexei Starovoitov
2015-03-02 18:25 ` Tom Zanussi
2015-03-02 18:43 ` Steven Rostedt
2015-03-02 16:01 ` [PATCH 08/15] tracing: Make kmem memory allocation tracepoints conditional Tom Zanussi
2015-03-02 16:01 ` [PATCH 09/15] tracing: Add kmalloc/kfree macros Tom Zanussi
2015-03-02 16:01 ` [PATCH 10/15] bpf: Make tracing_map use kmalloc/kfree_notrace() Tom Zanussi
2015-03-02 16:01 ` [PATCH 11/15] tracing: Add a per-event-trigger 'paused' field Tom Zanussi
2015-03-02 16:01 ` [PATCH 12/15] tracing: Add 'hist' event trigger command Tom Zanussi
2015-03-02 16:01 ` [PATCH 13/15] tracing: Add sorting to hist triggers Tom Zanussi
2015-03-02 16:01 ` [PATCH 14/15] tracing: Add enable_hist/disable_hist triggers Tom Zanussi
2015-03-02 16:01 ` [PATCH 15/15] tracing: Add 'hist' trigger Documentation Tom Zanussi
2015-03-03 2:25 ` [PATCH v2 00/15] tracing: 'hist' triggers Masami Hiramatsu
2015-03-03 14:47 ` Tom Zanussi
-- strict thread matches above, loose matches on Subject: below --
2015-03-02 18:40 [PATCH 07/15] mm: Add ___GFP_NOTRACE Alexei Starovoitov
2015-03-02 18:54 ` Tom Zanussi
2015-03-02 19:24 Alexei Starovoitov
2015-03-02 19:33 ` Steven Rostedt
2015-03-02 19:29 Alexei Starovoitov
2015-03-02 22:04 ` Tom Zanussi
2015-03-02 23:21 ` Alexei Starovoitov
2015-03-02 19:52 Alexei Starovoitov
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=1425319406.20819.9.camel@picadillo \
--to=tom.zanussi@linux.intel.com \
--cc=andi@firstfloor.org \
--cc=ast@plumgrid.com \
--cc=linux-kernel@vger.kernel.org \
--cc=masami.hiramatsu.pt@hitachi.com \
--cc=namhyung@kernel.org \
--cc=rostedt@goodmis.org \
/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.