Peter Zijlstra <[email protected]> writes: > On Wed, Aug 20, 2014 at 03:36:01PM +0300, Alexander Shishkin wrote: >> For pmus that don't support scatter-gather for AUX data in hardware, it >> might still make sense to implement software double buffering to avoid >> losing data while the user is reading data out. For this purpose, add >> a pmu capability that guarantees multiple high-order chunks for AUX buffer, >> so that the pmu driver can do switchover tricks. > > Please expand this with more detail on how to use this.
Sure. >> Signed-off-by: Alexander Shishkin <[email protected]> >> --- >> include/linux/perf_event.h | 1 + >> kernel/events/ring_buffer.c | 15 ++++++++++++++- >> 2 files changed, 15 insertions(+), 1 deletion(-) >> >> diff --git a/include/linux/perf_event.h b/include/linux/perf_event.h >> index fe10bf6f94..1e7b659b49 100644 >> --- a/include/linux/perf_event.h >> +++ b/include/linux/perf_event.h >> @@ -172,6 +172,7 @@ struct perf_event; >> */ >> #define PERF_PMU_CAP_NO_INTERRUPT 0x01 >> #define PERF_PMU_CAP_AUX_NO_SG 0x02 >> +#define PERF_PMU_CAP_AUX_SW_DOUBLEBUF 0x04 >> >> /** >> * struct pmu - generic performance monitoring unit >> diff --git a/kernel/events/ring_buffer.c b/kernel/events/ring_buffer.c >> index d10919ca42..f5ee3669f8 100644 >> --- a/kernel/events/ring_buffer.c >> +++ b/kernel/events/ring_buffer.c >> @@ -286,9 +286,22 @@ int rb_alloc_aux(struct ring_buffer *rb, struct >> perf_event *event, >> if (!has_aux(event)) >> return -ENOTSUPP; >> >> - if (event->pmu->capabilities & PERF_PMU_CAP_AUX_NO_SG) >> + if (event->pmu->capabilities & PERF_PMU_CAP_AUX_NO_SG) { >> order = get_order(nr_pages * PAGE_SIZE); >> >> + /* >> + * PMU requests more than one contiguous chunks of memory >> + * for SW double buffering >> + */ >> + if ((event->pmu->capabilities & PERF_PMU_CAP_AUX_SW_DOUBLEBUF) >> && >> + !overwrite) { >> + if (!order) >> + return -EINVAL; >> + >> + order--; >> + } >> + } > > In particular this looks like it will allocate double the total amount > of pages and 'loose' half of them. There is no corresponding code in the > free path to collect them. This code makes the biggest high order allocation no bigger than half of the total requested size. Then, when I allocate the high-order chunks, I do a split_page() on them and everywhere else in the code they are treated as individual pages, including the free path. So this patch has no implication on freeing. Is this your concern? Regards, -- Alex -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
