[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20100528155719.GA10141@kryptos.osrc.amd.com>
Date: Fri, 28 May 2010 17:57:20 +0200
From: Borislav Petkov <bp@...64.org>
To: Peter Zijlstra <peterz@...radead.org>
Cc: Ingo Molnar <mingo@...e.hu>, Borislav Petkov <bp@...en8.de>,
Frederic Weisbecker <fweisbec@...il.com>,
Steven Rostedt <rostedt@...dmis.org>,
Arnaldo Carvalho de Melo <acme@...hat.com>,
Lin Ming <ming.m.lin@...el.com>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/2] perf: Add persistent events
From: Peter Zijlstra <peterz@...radead.org>
Date: Fri, May 28, 2010 at 05:17:40PM +0200
> On Fri, 2010-05-28 at 16:33 +0200, Ingo Molnar wrote:
>
> > > 2) get these things a buffer, perf_events as created don't actually
> > > have an output buffer, normally that is created at mmap() time, but
> > > since you cannot mmap() a kernel side event, it doesn't get to have
> > > a buffer. This could be done by extracting perf_mmap_data_alloc()
> > > into a sensible interface.
> >
> > #2 could be a new syscall: sys_create_ring_buffer or so?
>
> No, they need a buffer in-kernel, syscalls aren't the ideal tool for
> that :-)
Yeah, I need a per-cpu buffer ready at event registration/enable time,
maybe even have perf_event_create_kernel_counter() take care of that
buffer allocation with a flag or similar prior to enabling the event...
> I've got patches refactoring the whole buffer stuff to make it more a
> self-contained entity.
Can I see those when you're done so that I can base my stuff on top?
Thanks.
--
Regards/Gruss,
Boris.
Operating Systems Research Center
Advanced Micro Devices, Inc.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists