From: will.deacon@arm.com (Will Deacon)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 2/2] perf/aux: Ensure aux_wakeup represents most recent wakeup index
Date: Fri, 4 Aug 2017 15:42:35 +0100 [thread overview]
Message-ID: <20170804144235.GA6780@arm.com> (raw)
In-Reply-To: <87lgn4udp3.fsf@ashishki-desk.ger.corp.intel.com>
Hi Alexander,
Thanks for having a look at these.
On Mon, Jul 31, 2017 at 01:02:16PM +0300, Alexander Shishkin wrote:
> Will Deacon <will.deacon@arm.com> writes:
>
> > The aux_watermark member of struct ring_buffer represents the period (in
> > terms of bytes) at which wakeup events should be generated when data is
> > written to the aux buffer in non-snapshot mode. On hardware that cannot
> > generate an interrupt when the aux_head reaches an arbitrary wakeup index
>
> Curious: how do you support non-snapshot trace collection on such
> hardware?
The watermark is constrained to lie on a page boundary, so as long as the
buffer is at least a page (which it is!), we end up rounding up to the next
page boundary, with lots of fun and games to avoid going past the head.
> > (such as ARM SPE), the aux_head sampled from handle->head in
> > perf_aux_output_{skip,end} may in fact be past the wakeup index. This
>
> I think this is also true of hw where the interrupt is not
> precise. Thanks for looking at this.
Yes, it all looks like "skid" to userspace.
> > can lead to wakeup slowly falling behind the head. For example, consider
> > the case where hardware can only generate an interrupt on a page-boundary
> > and the aux buffer is initialised as follows:
> >
> > // Buffer size is 2 * PAGE_SIZE
> > rb->aux_head = rb->aux_wakeup = 0
> > rb->aux_watermark = PAGE_SIZE / 2
> >
> > following the first perf_aux_output_begin call, the handle is
> > initialised with:
> >
> > handle->head = 0
> > handle->size = 2 * PAGE_SIZE
> > handle->wakeup = PAGE_SIZE / 2
> >
> > and the hardware will be programmed to generate an interrupt at
> > PAGE_SIZE.
> >
> > When the interrupt is raised, the hardware head will be at PAGE_SIZE,
> > so calling perf_aux_output_end(handle, PAGE_SIZE) puts the ring buffer
> > into the following state:
> >
> > rb->aux_head = PAGE_SIZE
> > rb->aux_wakeup = PAGE_SIZE / 2
> > rb->aux_watermark = PAGE_SIZE / 2
> >
> > and then the next call to perf_aux_output_begin will result in:
> >
> > handle->head = handle->wakeup = PAGE_SIZE
> >
> > for which the semantics are unclear and, for a smaller aux_watermark
> > (e.g. PAGE_SIZE / 4), then the wakeup would in fact be behind head at
> > this point.
> >
> > This patch fixes the problem by rounding down the aux_head (as sampled
> > from the handle) to the nearest aux_watermark boundary when updating
> > rb->aux_wakeup, therefore taking into account any overruns by the
> > hardware.
>
> Let's add a small comment to the @aux_wakeup field definition? Other
> than that,
Good thinking; I'll do that.
> Acked-by: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Thanks!
Will
WARNING: multiple messages have this Message-ID (diff)
From: Will Deacon <will.deacon@arm.com>
To: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: linux-kernel@vger.kernel.org, mark.rutland@arm.com,
linux-arm-kernel@lists.infradead.org,
Peter Zijlstra <peterz@infradead.org>
Subject: Re: [PATCH 2/2] perf/aux: Ensure aux_wakeup represents most recent wakeup index
Date: Fri, 4 Aug 2017 15:42:35 +0100 [thread overview]
Message-ID: <20170804144235.GA6780@arm.com> (raw)
In-Reply-To: <87lgn4udp3.fsf@ashishki-desk.ger.corp.intel.com>
Hi Alexander,
Thanks for having a look at these.
On Mon, Jul 31, 2017 at 01:02:16PM +0300, Alexander Shishkin wrote:
> Will Deacon <will.deacon@arm.com> writes:
>
> > The aux_watermark member of struct ring_buffer represents the period (in
> > terms of bytes) at which wakeup events should be generated when data is
> > written to the aux buffer in non-snapshot mode. On hardware that cannot
> > generate an interrupt when the aux_head reaches an arbitrary wakeup index
>
> Curious: how do you support non-snapshot trace collection on such
> hardware?
The watermark is constrained to lie on a page boundary, so as long as the
buffer is at least a page (which it is!), we end up rounding up to the next
page boundary, with lots of fun and games to avoid going past the head.
> > (such as ARM SPE), the aux_head sampled from handle->head in
> > perf_aux_output_{skip,end} may in fact be past the wakeup index. This
>
> I think this is also true of hw where the interrupt is not
> precise. Thanks for looking at this.
Yes, it all looks like "skid" to userspace.
> > can lead to wakeup slowly falling behind the head. For example, consider
> > the case where hardware can only generate an interrupt on a page-boundary
> > and the aux buffer is initialised as follows:
> >
> > // Buffer size is 2 * PAGE_SIZE
> > rb->aux_head = rb->aux_wakeup = 0
> > rb->aux_watermark = PAGE_SIZE / 2
> >
> > following the first perf_aux_output_begin call, the handle is
> > initialised with:
> >
> > handle->head = 0
> > handle->size = 2 * PAGE_SIZE
> > handle->wakeup = PAGE_SIZE / 2
> >
> > and the hardware will be programmed to generate an interrupt at
> > PAGE_SIZE.
> >
> > When the interrupt is raised, the hardware head will be at PAGE_SIZE,
> > so calling perf_aux_output_end(handle, PAGE_SIZE) puts the ring buffer
> > into the following state:
> >
> > rb->aux_head = PAGE_SIZE
> > rb->aux_wakeup = PAGE_SIZE / 2
> > rb->aux_watermark = PAGE_SIZE / 2
> >
> > and then the next call to perf_aux_output_begin will result in:
> >
> > handle->head = handle->wakeup = PAGE_SIZE
> >
> > for which the semantics are unclear and, for a smaller aux_watermark
> > (e.g. PAGE_SIZE / 4), then the wakeup would in fact be behind head at
> > this point.
> >
> > This patch fixes the problem by rounding down the aux_head (as sampled
> > from the handle) to the nearest aux_watermark boundary when updating
> > rb->aux_wakeup, therefore taking into account any overruns by the
> > hardware.
>
> Let's add a small comment to the @aux_wakeup field definition? Other
> than that,
Good thinking; I'll do that.
> Acked-by: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Thanks!
Will
next prev parent reply other threads:[~2017-08-04 14:42 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-07-28 16:54 [PATCH 1/2] perf/aux: Make aux_{head, wakeup} ring_buffer members long Will Deacon
2017-07-28 16:54 ` [PATCH 1/2] perf/aux: Make aux_{head,wakeup} " Will Deacon
2017-07-28 16:54 ` [PATCH 2/2] perf/aux: Ensure aux_wakeup represents most recent wakeup index Will Deacon
2017-07-28 16:54 ` Will Deacon
2017-07-31 10:02 ` Alexander Shishkin
2017-07-31 10:02 ` Alexander Shishkin
2017-08-04 14:42 ` Will Deacon [this message]
2017-08-04 14:42 ` Will Deacon
2017-07-31 10:28 ` [PATCH 1/2] perf/aux: Make aux_{head, wakeup} ring_buffer members long Alexander Shishkin
2017-07-31 10:28 ` [PATCH 1/2] perf/aux: Make aux_{head,wakeup} " Alexander Shishkin
2017-08-04 14:58 ` [PATCH 1/2] perf/aux: Make aux_{head, wakeup} " Will Deacon
2017-08-04 14:58 ` [PATCH 1/2] perf/aux: Make aux_{head,wakeup} " Will Deacon
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20170804144235.GA6780@arm.com \
--to=will.deacon@arm.com \
--cc=linux-arm-kernel@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.