* [RFC PATCH 0/2] splice patches for ftrace
@ 2009-02-09 6:15 Eduard - Gabriel Munteanu
2009-02-09 6:15 ` [RFC PATCH 1/2] trace: Move pipe waiting code out of tracing_read_pipe() Eduard - Gabriel Munteanu
` (3 more replies)
0 siblings, 4 replies; 10+ messages in thread
From: Eduard - Gabriel Munteanu @ 2009-02-09 6:15 UTC (permalink / raw)
To: mingo; +Cc: fweisbec, penberg, rostedt, Eduard - Gabriel Munteanu,
linux-kernel
Hi,
This implements splice support so we can use it in kmemtrace-user. Please
check it out and tell me what you think.
The "RFC" in the subject reads like "I tested this the best I could,
although kmemtrace-user isn't still ready.". As we speak, I'm working on
making kmemtrace over ftrace and kmemtrace-user work together nicely.
Cheers,
Eduard
Eduard - Gabriel Munteanu (2):
trace: Move pipe waiting code out of tracing_read_pipe().
trace: splice support for tracing_pipe
kernel/trace/trace.c | 205 +++++++++++++++++++++++++++++++++++++++++++-------
kernel/trace/trace.h | 6 ++
2 files changed, 182 insertions(+), 29 deletions(-)
^ permalink raw reply [flat|nested] 10+ messages in thread
* [RFC PATCH 1/2] trace: Move pipe waiting code out of tracing_read_pipe().
2009-02-09 6:15 [RFC PATCH 0/2] splice patches for ftrace Eduard - Gabriel Munteanu
@ 2009-02-09 6:15 ` Eduard - Gabriel Munteanu
2009-02-09 6:15 ` [RFC PATCH 2/2] trace: splice support for tracing_pipe Eduard - Gabriel Munteanu
` (2 subsequent siblings)
3 siblings, 0 replies; 10+ messages in thread
From: Eduard - Gabriel Munteanu @ 2009-02-09 6:15 UTC (permalink / raw)
To: mingo; +Cc: fweisbec, penberg, rostedt, Eduard - Gabriel Munteanu,
linux-kernel
This moves the pipe waiting code from tracing_read_pipe() into
tracing_wait_pipe(), which is useful to implement other fops, like
splice_read.
Signed-off-by: Eduard - Gabriel Munteanu <eduard.munteanu@linux360.ro>
---
kernel/trace/trace.c | 69 +++++++++++++++++++++++++++++---------------------
1 files changed, 40 insertions(+), 29 deletions(-)
diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
index ef4dbac..130c4f5 100644
--- a/kernel/trace/trace.c
+++ b/kernel/trace/trace.c
@@ -2359,37 +2359,15 @@ tracing_poll_pipe(struct file *filp, poll_table *poll_table)
}
}
-/*
- * Consumer reader.
- */
-static ssize_t
-tracing_read_pipe(struct file *filp, char __user *ubuf,
- size_t cnt, loff_t *ppos)
+/* Must be called with trace_types_lock mutex held. */
+static int tracing_wait_pipe(struct file *filp)
{
struct trace_iterator *iter = filp->private_data;
- ssize_t sret;
-
- /* return any leftover data */
- sret = trace_seq_to_user(&iter->seq, ubuf, cnt);
- if (sret != -EBUSY)
- return sret;
-
- trace_seq_reset(&iter->seq);
- mutex_lock(&trace_types_lock);
- if (iter->trace->read) {
- sret = iter->trace->read(iter, filp, ubuf, cnt, ppos);
- if (sret)
- goto out;
- }
-
-waitagain:
- sret = 0;
while (trace_empty(iter)) {
if ((filp->f_flags & O_NONBLOCK)) {
- sret = -EAGAIN;
- goto out;
+ return -EAGAIN;
}
/*
@@ -2414,12 +2392,11 @@ waitagain:
iter->tr->waiter = NULL;
if (signal_pending(current)) {
- sret = -EINTR;
- goto out;
+ return -EINTR;
}
if (iter->trace != current_trace)
- goto out;
+ return 0;
/*
* We block until we read something and tracing is disabled.
@@ -2436,9 +2413,43 @@ waitagain:
continue;
}
+ return 1;
+}
+
+/*
+ * Consumer reader.
+ */
+static ssize_t
+tracing_read_pipe(struct file *filp, char __user *ubuf,
+ size_t cnt, loff_t *ppos)
+{
+ struct trace_iterator *iter = filp->private_data;
+ ssize_t sret;
+
+ /* return any leftover data */
+ sret = trace_seq_to_user(&iter->seq, ubuf, cnt);
+ if (sret != -EBUSY)
+ return sret;
+
+ trace_seq_reset(&iter->seq);
+
+ mutex_lock(&trace_types_lock);
+ if (iter->trace->read) {
+ sret = iter->trace->read(iter, filp, ubuf, cnt, ppos);
+ if (sret)
+ goto out;
+ }
+
+waitagain:
+ sret = tracing_wait_pipe(filp);
+ if (sret <= 0)
+ goto out;
+
/* stop when tracing is finished */
- if (trace_empty(iter))
+ if (trace_empty(iter)) {
+ sret = 0;
goto out;
+ }
if (cnt >= PAGE_SIZE)
cnt = PAGE_SIZE - 1;
--
1.6.0.6
^ permalink raw reply related [flat|nested] 10+ messages in thread
* [RFC PATCH 2/2] trace: splice support for tracing_pipe
2009-02-09 6:15 [RFC PATCH 0/2] splice patches for ftrace Eduard - Gabriel Munteanu
2009-02-09 6:15 ` [RFC PATCH 1/2] trace: Move pipe waiting code out of tracing_read_pipe() Eduard - Gabriel Munteanu
@ 2009-02-09 6:15 ` Eduard - Gabriel Munteanu
2009-02-09 9:04 ` Ingo Molnar
2009-02-09 15:49 ` Steven Rostedt
2009-02-09 14:10 ` [RFC PATCH 0/2] splice patches for ftrace Steven Rostedt
2009-02-09 14:43 ` Pekka Enberg
3 siblings, 2 replies; 10+ messages in thread
From: Eduard - Gabriel Munteanu @ 2009-02-09 6:15 UTC (permalink / raw)
To: mingo; +Cc: fweisbec, penberg, rostedt, Eduard - Gabriel Munteanu,
linux-kernel
Added and implemented tracing_pipe_fops->splice_read(). This allows
userspace programs to get tracing data more efficiently.
Signed-off-by: Eduard - Gabriel Munteanu <eduard.munteanu@linux360.ro>
---
kernel/trace/trace.c | 136 ++++++++++++++++++++++++++++++++++++++++++++++++++
kernel/trace/trace.h | 6 ++
2 files changed, 142 insertions(+), 0 deletions(-)
diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
index 130c4f5..5b136ed 100644
--- a/kernel/trace/trace.c
+++ b/kernel/trace/trace.c
@@ -31,6 +31,7 @@
#include <linux/fs.h>
#include <linux/kprobes.h>
#include <linux/writeback.h>
+#include <linux/splice.h>
#include <linux/stacktrace.h>
#include <linux/ring_buffer.h>
@@ -364,6 +365,25 @@ ssize_t trace_seq_to_user(struct trace_seq *s, char __user *ubuf, size_t cnt)
return cnt;
}
+ssize_t trace_seq_to_buffer(struct trace_seq *s, void *buf, size_t cnt)
+{
+ int len;
+ void *ret;
+
+ if (s->len <= s->readpos)
+ return -EBUSY;
+
+ len = s->len - s->readpos;
+ if (cnt > len)
+ cnt = len;
+ ret = memcpy(buf, s->buffer + s->readpos, cnt);
+ if (!ret)
+ return -EFAULT;
+
+ s->readpos += len;
+ return cnt;
+}
+
static void
trace_print_seq(struct seq_file *m, struct trace_seq *s)
{
@@ -2495,6 +2515,121 @@ out:
return sret;
}
+static void tracing_pipe_buf_release(struct pipe_inode_info *pipe,
+ struct pipe_buffer *buf)
+{
+ __free_page(buf->page);
+}
+
+static void tracing_spd_release_pipe(struct splice_pipe_desc *spd,
+ unsigned int idx)
+{
+ __free_page(spd->pages[idx]);
+}
+
+static struct pipe_buf_operations tracing_pipe_buf_ops = {
+ .can_merge = 0,
+ .map = generic_pipe_buf_map,
+ .unmap = generic_pipe_buf_unmap,
+ .confirm = generic_pipe_buf_confirm,
+ .release = tracing_pipe_buf_release,
+ .steal = generic_pipe_buf_steal,
+ .get = generic_pipe_buf_get,
+};
+
+static ssize_t tracing_splice_read_pipe(struct file *filp,
+ loff_t *ppos,
+ struct pipe_inode_info *pipe,
+ size_t len,
+ unsigned int flags)
+{
+ struct page *pages[PIPE_BUFFERS];
+ struct partial_page partial[PIPE_BUFFERS];
+ struct trace_iterator *iter = filp->private_data;
+ struct splice_pipe_desc spd = {
+ .pages = pages,
+ .partial = partial,
+ .nr_pages = 0, /* This gets updated below. */
+ .flags = flags,
+ .ops = &tracing_pipe_buf_ops,
+ .spd_release = tracing_spd_release_pipe,
+ };
+ ssize_t ret;
+ size_t count, rem;
+ unsigned int i;
+
+ mutex_lock(&trace_types_lock);
+
+ if (iter->trace->splice_read) {
+ ret = iter->trace->splice_read(iter, filp,
+ ppos, pipe, len, flags);
+ if (ret)
+ goto out;
+ }
+
+ ret = tracing_wait_pipe(filp);
+ if (ret <= 0)
+ goto out;
+
+ if (!iter->ent && !find_next_entry_inc(iter)) {
+ ret = -EFAULT;
+ goto out;
+ }
+
+ /* Fill as many pages as possible. */
+ for (i = 0, rem = len; i < PIPE_BUFFERS && rem; i++) {
+ pages[i] = alloc_page(GFP_KERNEL);
+
+ /* Seq buffer is page-sized, exactly what we need. */
+ for (;;) {
+ count = iter->seq.len;
+ ret = print_trace_line(iter);
+ count = iter->seq.len - count;
+ if (rem < count) {
+ rem = 0;
+ iter->seq.len -= count;
+ break;
+ }
+ if (ret == TRACE_TYPE_PARTIAL_LINE) {
+ iter->seq.len -= count;
+ break;
+ }
+
+ trace_consume(iter);
+ rem -= count;
+ if (!find_next_entry_inc(iter)) {
+ rem = 0;
+ iter->ent = NULL;
+ break;
+ }
+ }
+
+ /* Copy the data into the page, so we can start over. */
+ ret = trace_seq_to_buffer(&iter->seq,
+ page_address(pages[i]),
+ iter->seq.len);
+ if (ret < 0) {
+ __free_page(pages[i]);
+ break;
+ }
+ partial[i].offset = 0;
+ partial[i].len = iter->seq.len;
+
+ trace_seq_reset(&iter->seq);
+ }
+
+ mutex_unlock(&trace_types_lock);
+
+ spd.nr_pages = i;
+
+ return splice_to_pipe(pipe, &spd);
+
+out:
+ mutex_unlock(&trace_types_lock);
+
+ return ret;
+}
+
static ssize_t
tracing_entries_read(struct file *filp, char __user *ubuf,
size_t cnt, loff_t *ppos)
@@ -2658,6 +2793,7 @@ static struct file_operations tracing_pipe_fops = {
.open = tracing_open_pipe,
.poll = tracing_poll_pipe,
.read = tracing_read_pipe,
+ .splice_read = tracing_splice_read_pipe,
.release = tracing_release_pipe,
};
diff --git a/kernel/trace/trace.h b/kernel/trace/trace.h
index f2742fb..d58c305 100644
--- a/kernel/trace/trace.h
+++ b/kernel/trace/trace.h
@@ -352,6 +352,12 @@ struct tracer {
ssize_t (*read)(struct trace_iterator *iter,
struct file *filp, char __user *ubuf,
size_t cnt, loff_t *ppos);
+ ssize_t (*splice_read)(struct trace_iterator *iter,
+ struct file *filp,
+ loff_t *ppos,
+ struct pipe_inode_info *pipe,
+ size_t len,
+ unsigned int flags);
#ifdef CONFIG_FTRACE_STARTUP_TEST
int (*selftest)(struct tracer *trace,
struct trace_array *tr);
--
1.6.0.6
^ permalink raw reply related [flat|nested] 10+ messages in thread
* Re: [RFC PATCH 2/2] trace: splice support for tracing_pipe
2009-02-09 6:15 ` [RFC PATCH 2/2] trace: splice support for tracing_pipe Eduard - Gabriel Munteanu
@ 2009-02-09 9:04 ` Ingo Molnar
2009-02-09 15:49 ` Steven Rostedt
1 sibling, 0 replies; 10+ messages in thread
From: Ingo Molnar @ 2009-02-09 9:04 UTC (permalink / raw)
To: Eduard - Gabriel Munteanu; +Cc: fweisbec, penberg, rostedt, linux-kernel
* Eduard - Gabriel Munteanu <eduard.munteanu@linux360.ro> wrote:
> Added and implemented tracing_pipe_fops->splice_read(). This allows
> userspace programs to get tracing data more efficiently.
Cool!
The structure of the splice state machine looks good - havent tested it yet.
A few comments:
> +static struct pipe_buf_operations tracing_pipe_buf_ops = {
> + .can_merge = 0,
> + .map = generic_pipe_buf_map,
> + .unmap = generic_pipe_buf_unmap,
> + .confirm = generic_pipe_buf_confirm,
> + .release = tracing_pipe_buf_release,
> + .steal = generic_pipe_buf_steal,
> + .get = generic_pipe_buf_get,
> +};
this looks nicer:
static struct pipe_buf_operations tracing_pipe_buf_ops = {
.can_merge = 0,
.map = generic_pipe_buf_map,
.unmap = generic_pipe_buf_unmap,
.confirm = generic_pipe_buf_confirm,
.release = tracing_pipe_buf_release,
.steal = generic_pipe_buf_steal,
.get = generic_pipe_buf_get,
};
(and this is how we do these things elsewhere in the tracing code)
ditto:
> + struct splice_pipe_desc spd = {
> + .pages = pages,
> + .partial = partial,
> + .nr_pages = 0, /* This gets updated below. */
> + .flags = flags,
> + .ops = &tracing_pipe_buf_ops,
> + .spd_release = tracing_spd_release_pipe,
> + };
+ for (i = 0, rem = len; i < PIPE_BUFFERS && rem; i++) {
+ pages[i] = alloc_page(GFP_KERNEL);
+
+ /* Seq buffer is page-sized, exactly what we need. */
+ for (;;) {
Ok, that's a minor bug: should check for NULL alloc_page() return.
> +out:
> + mutex_unlock(&trace_types_lock);
> +
> + return ret;
please name this label as 'out_err' - which it really is. We generally use the
'out:' label for error-less exits.
Btw., this is how we do structure initializations:
> .open = tracing_open_pipe,
> .poll = tracing_poll_pipe,
> .read = tracing_read_pipe,
> + .splice_read = tracing_splice_read_pipe,
> .release = tracing_release_pipe,
> };
One more thing, i'd suggest to split this loop (which is an iterator in a larger
loop):
+ /* Seq buffer is page-sized, exactly what we need. */
+ for (;;) {
+ count = iter->seq.len;
+ ret = print_trace_line(iter);
[...]
+ }
Out into a separate helper inline function. This really is a "fill in pipe page"
logic and having it separate makes it easier to review the splice-loop code pattern
itself.
Thanks,
Ingo
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [RFC PATCH 0/2] splice patches for ftrace
2009-02-09 6:15 [RFC PATCH 0/2] splice patches for ftrace Eduard - Gabriel Munteanu
2009-02-09 6:15 ` [RFC PATCH 1/2] trace: Move pipe waiting code out of tracing_read_pipe() Eduard - Gabriel Munteanu
2009-02-09 6:15 ` [RFC PATCH 2/2] trace: splice support for tracing_pipe Eduard - Gabriel Munteanu
@ 2009-02-09 14:10 ` Steven Rostedt
2009-02-09 14:17 ` Ingo Molnar
2009-02-09 14:43 ` Pekka Enberg
3 siblings, 1 reply; 10+ messages in thread
From: Steven Rostedt @ 2009-02-09 14:10 UTC (permalink / raw)
To: Eduard - Gabriel Munteanu; +Cc: mingo, fweisbec, penberg, linux-kernel
On Mon, 9 Feb 2009, Eduard - Gabriel Munteanu wrote:
> Hi,
>
> This implements splice support so we can use it in kmemtrace-user. Please
> check it out and tell me what you think.
>
> The "RFC" in the subject reads like "I tested this the best I could,
> although kmemtrace-user isn't still ready.". As we speak, I'm working on
> making kmemtrace over ftrace and kmemtrace-user work together nicely.
Hi Eduard!
Thanks, I'll give it a test. I've been playing on my spare time with
a ring buffer splice interface. But I've not had the time to get it
working fully. My version would be a binary only interface, but I really
like the text interface you have.
You can look at my old changes at:
git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-2.6-trace.git
The branch tip/splice-broken
As the name suggests, it is still broken ;-)
-- Steve
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [RFC PATCH 0/2] splice patches for ftrace
2009-02-09 14:10 ` [RFC PATCH 0/2] splice patches for ftrace Steven Rostedt
@ 2009-02-09 14:17 ` Ingo Molnar
0 siblings, 0 replies; 10+ messages in thread
From: Ingo Molnar @ 2009-02-09 14:17 UTC (permalink / raw)
To: Steven Rostedt; +Cc: Eduard - Gabriel Munteanu, fweisbec, penberg, linux-kernel
* Steven Rostedt <rostedt@goodmis.org> wrote:
>
> On Mon, 9 Feb 2009, Eduard - Gabriel Munteanu wrote:
>
> > Hi,
> >
> > This implements splice support so we can use it in kmemtrace-user. Please
> > check it out and tell me what you think.
> >
> > The "RFC" in the subject reads like "I tested this the best I could,
> > although kmemtrace-user isn't still ready.". As we speak, I'm working on
> > making kmemtrace over ftrace and kmemtrace-user work together nicely.
>
> Hi Eduard!
>
> Thanks, I'll give it a test. I've been playing on my spare time with
> a ring buffer splice interface. But I've not had the time to get it
> working fully. My version would be a binary only interface, but I really
> like the text interface you have.
>
> You can look at my old changes at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-2.6-trace.git
>
> The branch tip/splice-broken
>
> As the name suggests, it is still broken ;-)
I'd suggest we pick up Eduard's, with the fixes i suggested - because
they clearly work for his kmemtrace utility!
Then pick up whatever is left in your branch.
Ingo
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [RFC PATCH 0/2] splice patches for ftrace
2009-02-09 6:15 [RFC PATCH 0/2] splice patches for ftrace Eduard - Gabriel Munteanu
` (2 preceding siblings ...)
2009-02-09 14:10 ` [RFC PATCH 0/2] splice patches for ftrace Steven Rostedt
@ 2009-02-09 14:43 ` Pekka Enberg
3 siblings, 0 replies; 10+ messages in thread
From: Pekka Enberg @ 2009-02-09 14:43 UTC (permalink / raw)
To: Eduard - Gabriel Munteanu; +Cc: mingo, fweisbec, rostedt, linux-kernel
On Mon, 2009-02-09 at 08:15 +0200, Eduard - Gabriel Munteanu wrote:
> This implements splice support so we can use it in kmemtrace-user. Please
> check it out and tell me what you think.
I am not a splice or ftrace expert but modulo the comments from Ingo:
Acked-by: Pekka Enberg <penberg@cs.helsinki.fi>
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [RFC PATCH 2/2] trace: splice support for tracing_pipe
2009-02-09 6:15 ` [RFC PATCH 2/2] trace: splice support for tracing_pipe Eduard - Gabriel Munteanu
2009-02-09 9:04 ` Ingo Molnar
@ 2009-02-09 15:49 ` Steven Rostedt
2009-02-11 12:35 ` Ingo Molnar
1 sibling, 1 reply; 10+ messages in thread
From: Steven Rostedt @ 2009-02-09 15:49 UTC (permalink / raw)
To: Eduard - Gabriel Munteanu; +Cc: mingo, fweisbec, penberg, linux-kernel
On Mon, 9 Feb 2009, Eduard - Gabriel Munteanu wrote:
> +
> +static ssize_t tracing_splice_read_pipe(struct file *filp,
> + loff_t *ppos,
> + struct pipe_inode_info *pipe,
> + size_t len,
> + unsigned int flags)
> +{
> + struct page *pages[PIPE_BUFFERS];
> + struct partial_page partial[PIPE_BUFFERS];
> + struct trace_iterator *iter = filp->private_data;
> + struct splice_pipe_desc spd = {
> + .pages = pages,
> + .partial = partial,
> + .nr_pages = 0, /* This gets updated below. */
> + .flags = flags,
> + .ops = &tracing_pipe_buf_ops,
> + .spd_release = tracing_spd_release_pipe,
> + };
Note, this is getting a little stack heavy. It is still in bounds,
but I get very nervous when I see structure arrays on the stack.
If either the structure or the array grows large, we can be in trouble.
-- Steve
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [RFC PATCH 2/2] trace: splice support for tracing_pipe
2009-02-09 15:49 ` Steven Rostedt
@ 2009-02-11 12:35 ` Ingo Molnar
2009-02-11 13:19 ` Frederic Weisbecker
0 siblings, 1 reply; 10+ messages in thread
From: Ingo Molnar @ 2009-02-11 12:35 UTC (permalink / raw)
To: Steven Rostedt; +Cc: Eduard - Gabriel Munteanu, fweisbec, penberg, linux-kernel
* Steven Rostedt <rostedt@goodmis.org> wrote:
> On Mon, 9 Feb 2009, Eduard - Gabriel Munteanu wrote:
> > +
> > +static ssize_t tracing_splice_read_pipe(struct file *filp,
> > + loff_t *ppos,
> > + struct pipe_inode_info *pipe,
> > + size_t len,
> > + unsigned int flags)
> > +{
> > + struct page *pages[PIPE_BUFFERS];
> > + struct partial_page partial[PIPE_BUFFERS];
> > + struct trace_iterator *iter = filp->private_data;
> > + struct splice_pipe_desc spd = {
> > + .pages = pages,
> > + .partial = partial,
> > + .nr_pages = 0, /* This gets updated below. */
> > + .flags = flags,
> > + .ops = &tracing_pipe_buf_ops,
> > + .spd_release = tracing_spd_release_pipe,
> > + };
>
> Note, this is getting a little stack heavy. It is still in bounds,
> but I get very nervous when I see structure arrays on the stack.
> If either the structure or the array grows large, we can be in trouble.
Good point - but note that this is how splice support is implemented in
a number of other files - so if PIPE_BUFFERS or partial_page grows in
size, those places will fail too.
Ingo
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [RFC PATCH 2/2] trace: splice support for tracing_pipe
2009-02-11 12:35 ` Ingo Molnar
@ 2009-02-11 13:19 ` Frederic Weisbecker
0 siblings, 0 replies; 10+ messages in thread
From: Frederic Weisbecker @ 2009-02-11 13:19 UTC (permalink / raw)
To: Ingo Molnar
Cc: Steven Rostedt, Eduard - Gabriel Munteanu, penberg, linux-kernel
On Wed, Feb 11, 2009 at 01:35:26PM +0100, Ingo Molnar wrote:
>
> * Steven Rostedt <rostedt@goodmis.org> wrote:
>
> > On Mon, 9 Feb 2009, Eduard - Gabriel Munteanu wrote:
> > > +
> > > +static ssize_t tracing_splice_read_pipe(struct file *filp,
> > > + loff_t *ppos,
> > > + struct pipe_inode_info *pipe,
> > > + size_t len,
> > > + unsigned int flags)
> > > +{
> > > + struct page *pages[PIPE_BUFFERS];
> > > + struct partial_page partial[PIPE_BUFFERS];
> > > + struct trace_iterator *iter = filp->private_data;
> > > + struct splice_pipe_desc spd = {
> > > + .pages = pages,
> > > + .partial = partial,
> > > + .nr_pages = 0, /* This gets updated below. */
> > > + .flags = flags,
> > > + .ops = &tracing_pipe_buf_ops,
> > > + .spd_release = tracing_spd_release_pipe,
> > > + };
> >
> > Note, this is getting a little stack heavy. It is still in bounds,
> > but I get very nervous when I see structure arrays on the stack.
> > If either the structure or the array grows large, we can be in trouble.
>
> Good point - but note that this is how splice support is implemented in
> a number of other files - so if PIPE_BUFFERS or partial_page grows in
> size, those places will fail too.
>
> Ingo
I first thought they can be declared as static, since the read_pipe functions
are not supposed to be reentrant, only one reader is allowed inside the pipe
(serialized with a global mutex).
But the mutex is released while waiting, and still, I guess it should be
reentrant one day if we plan to let the user having one trace_pipe per
cpu trace.
Would a dynamic allocation be too much overhead for that?
^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2009-02-11 13:20 UTC | newest]
Thread overview: 10+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2009-02-09 6:15 [RFC PATCH 0/2] splice patches for ftrace Eduard - Gabriel Munteanu
2009-02-09 6:15 ` [RFC PATCH 1/2] trace: Move pipe waiting code out of tracing_read_pipe() Eduard - Gabriel Munteanu
2009-02-09 6:15 ` [RFC PATCH 2/2] trace: splice support for tracing_pipe Eduard - Gabriel Munteanu
2009-02-09 9:04 ` Ingo Molnar
2009-02-09 15:49 ` Steven Rostedt
2009-02-11 12:35 ` Ingo Molnar
2009-02-11 13:19 ` Frederic Weisbecker
2009-02-09 14:10 ` [RFC PATCH 0/2] splice patches for ftrace Steven Rostedt
2009-02-09 14:17 ` Ingo Molnar
2009-02-09 14:43 ` Pekka Enberg
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox