On Fri, 14 Feb 2014 15:29:57 -0800
Bharath Ravi wrote:
> > @@ -5930,7 +5932,7 @@ static int allocate_trace_buffers(struct trace_array
> > *tr, int size)
> > static int new_instance_create(const char *name)
> > {
> > struct trace_array *tr;
> > - int ret;
> > + int ret,
On Tue, 29 Apr 2014 15:09:15 -0700
Bharath Ravi wrote:
> We'd actually considered doing just that, in an initial version of the patch.
> At the time, we'd decided in favour of allowing the user more explicit
> control over the buffer size, rather than auto expanding it. (The
> discussion on that
We'd actually considered doing just that, in an initial version of the patch.
At the time, we'd decided in favour of allowing the user more explicit
control over the buffer size, rather than auto expanding it. (The
discussion on that is here:
https://lkml.org/lkml/2013/7/1/617)
We could go back
We'd actually considered doing just that, in an initial version of the patch.
At the time, we'd decided in favour of allowing the user more explicit
control over the buffer size, rather than auto expanding it. (The
discussion on that is here:
https://lkml.org/lkml/2013/7/1/617)
We could go back
On Tue, 29 Apr 2014 15:09:15 -0700
Bharath Ravi rbhar...@google.com wrote:
We'd actually considered doing just that, in an initial version of the patch.
At the time, we'd decided in favour of allowing the user more explicit
control over the buffer size, rather than auto expanding it. (The
On Fri, 14 Feb 2014 15:29:57 -0800
Bharath Ravi rbhar...@google.com wrote:
@@ -5930,7 +5932,7 @@ static int allocate_trace_buffers(struct trace_array
*tr, int size)
static int new_instance_create(const char *name)
{
struct trace_array *tr;
- int ret;
+ int
On Fri, 14 Feb 2014 15:29:57 -0800
Bharath Ravi wrote:
> Hi Steven,
>
> Does this version of the patch look reasonable?
Sorry, your email got buried in my TODO list :-/
Anyway, what about if we make new instances act like the original
buffer does on start up? That is, have it start out as a
On Fri, 14 Feb 2014 15:29:57 -0800
Bharath Ravi rbhar...@google.com wrote:
Hi Steven,
Does this version of the patch look reasonable?
Sorry, your email got buried in my TODO list :-/
Anyway, what about if we make new instances act like the original
buffer does on start up? That is, have it
Hi Steven,
Does this version of the patch look reasonable?
--
Bharath Ravi | rbhar...@google.com
On Thu, Jan 23, 2014 at 11:37 AM, Bharath Ravi wrote:
>
> It is often memory efficient to start instances off with a smaller ring
> buffer size than the current default. This is particularly true
Hi Steven,
Does this version of the patch look reasonable?
--
Bharath Ravi | rbhar...@google.com
On Thu, Jan 23, 2014 at 11:37 AM, Bharath Ravi rbhar...@google.com wrote:
It is often memory efficient to start instances off with a smaller ring
buffer size than the current default. This is
It is often memory efficient to start instances off with a smaller ring
buffer size than the current default. This is particularly true on
systems with many cores, or when multiple ftrace instances are created,
where the current (higher) default value results in allocation failures.
The global
It is often memory efficient to start instances off with a smaller ring
buffer size than the current default. This is particularly true on
systems with many cores, or when multiple ftrace instances are created,
where the current (higher) default value results in allocation failures.
The global
12 matches
Mail list logo
