Re: [RFC PATCH v4] Unified trace buffer

[Steven Rostedt]

On Thu, 25 Sep 2008, Masami Hiramatsu wrote:

> Hi Steven,
> 
> Steven Rostedt wrote:
> > This version has been cleaned up a bit. I've been running it as
> > a back end to ftrace, and it has been handling pretty well.
> 
> Thank you for your great work.
> It seems good to me(especially, encapsulating events :)).

Thanks!

> 
> I have one request of enhancement.
> 
> > +static struct ring_buffer_per_cpu *
> > +ring_buffer_allocate_cpu_buffer(struct ring_buffer *buffer, int cpu)
> > +{
> [...]
> > +	cpu_buffer->pages = kzalloc_node(ALIGN(sizeof(void *) * pages,
> > +					       cache_line_size()), GFP_KERNEL,
> > +					 cpu_to_node(cpu));
> 
> Here, you are using a slab object for page managing array,
> the largest object size is 128KB(x86-64), so it can contain
> 16K pages = 64MB.
> 
> As I had improved relayfs, in some rare case(on 64bit arch),
> we'd like to use larger buffer than 64MB.
> 
> http://sourceware.org/ml/systemtap/2008-q2/msg00103.html
> 
> So, I think similar hack can be applicable.
> 
> Would it be acceptable for the next version?

I would like to avoid using vmalloc as much as possible, but I do see the 
limitation here. Here's my compromise.

Instead of using vmalloc if the page array is greater than one page, 
how about using vmalloc if the page array is greater than 
KMALLOC_MAX_SIZE?

This would let us keep the vmap area free unless we have no choice.

-- Steve

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/