Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1490345 > unrolled thread

Re: [RFC PATCH 1/6] perf: Move mlock accounting to ring buffer allocation

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [RFC PATCH 1/6] perf: Move mlock accounting to ring buffer  allocation Andi Kleen <ak@linux.intel.com> - 2016-09-23 19:30 +0200
    Re: [RFC PATCH 1/6] perf: Move mlock accounting to ring buffer  allocation Peter Zijlstra <peterz@infradead.org> - 2016-09-23 22:30 +0200
      Re: [RFC PATCH 1/6] perf: Move mlock accounting to ring buffer allocation Alexander Shishkin <alexander.shishkin@linux.intel.com> - 2016-09-26 10:30 +0200
        Re: [RFC PATCH 1/6] perf: Move mlock accounting to ring buffer  allocation Peter Zijlstra <peterz@infradead.org> - 2016-09-26 11:10 +0200
          Re: [RFC PATCH 1/6] perf: Move mlock accounting to ring buffer allocation Alexander Shishkin <alexander.shishkin@linux.intel.com> - 2016-09-26 14:50 +0200
          Re: [RFC PATCH 1/6] perf: Move mlock accounting to ring buffer allocation Alexander Shishkin <alexander.shishkin@linux.intel.com> - 2016-09-26 18:20 +0200

#1490345 — Re: [RFC PATCH 1/6] perf: Move mlock accounting to ring buffer allocation

> Afaict there's no actual need to hide the AUX buffer for this sampling
> stuff; the user knows about all this and can simply mmap() the AUX part.
> The sample could either point to locations in the AUX buffer, or (as I
> think this code does) memcpy bits out.

This would work for perf, but not for the core dump case below.

> Ideally we'd pass the AUX-event into the syscall, that way you avoid all
> the find_aux_event crud. I'm not sure we want to overload the group_fd
> thing more (its already very hard to create counter groups in a cgroup
> for example) ..
> 
> Coredump was mentioned somewhere, but I'm not sure I've seen
> code/interfaces for that. How was that envisioned to work?

The idea was to have a rlimit that enables PT running as a ring buffer
in the background.  If something crashes the ring buffer is dumped
as part of the core dump, and then gdb can tell you how you crashed.
This extends what gdb already does explicitly today using perf
API calls.

-Andi

[toc] | [next] | [standalone]

#1490438

On Fri, Sep 23, 2016 at 10:26:15AM -0700, Andi Kleen wrote:
> > Afaict there's no actual need to hide the AUX buffer for this sampling
> > stuff; the user knows about all this and can simply mmap() the AUX part.
> > The sample could either point to locations in the AUX buffer, or (as I
> > think this code does) memcpy bits out.
> 
> This would work for perf, but not for the core dump case below.
> 
> > Ideally we'd pass the AUX-event into the syscall, that way you avoid all
> > the find_aux_event crud. I'm not sure we want to overload the group_fd
> > thing more (its already very hard to create counter groups in a cgroup
> > for example) ..
> > 
> > Coredump was mentioned somewhere, but I'm not sure I've seen
> > code/interfaces for that. How was that envisioned to work?
> 
> The idea was to have a rlimit that enables PT running as a ring buffer
> in the background.  If something crashes the ring buffer is dumped
> as part of the core dump, and then gdb can tell you how you crashed.
> This extends what gdb already does explicitly today using perf
> API calls.

Well, we could 'force' inject a VMA into the process's address space, we
do that for a few other things as well. It also makes for less
exceptions with the actual core dumping.

But the worry I have is the total amount of pinned memory. If you want
to inherit this on fork(), as is a reasonable expectation, then its
possible to quickly exceed the total amount of pinnable memory.

At which point we _should_ start failing fork(), which is a somewhat
unexpected, and undesirable side-effect.

Ideally we'd unpin the old buffers and repin the new buffers on context
switch, but that's impossible since faulting needs scheduling,
recursion, we loose.

I really want to see something sensible before we go do that.

[toc] | [prev] | [next] | [standalone]

#1491142 — Re: [RFC PATCH 1/6] perf: Move mlock accounting to ring buffer allocation

Peter Zijlstra <peterz@infradead.org> writes:

> Well, we could 'force' inject a VMA into the process's address space, we
> do that for a few other things as well. It also makes for less
> exceptions with the actual core dumping.

Threads then will end up with the same buffer (through sharing the mm),
but they can't really share trace buffers.

Also, system core dump is still a problem.

> But the worry I have is the total amount of pinned memory. If you want
> to inherit this on fork(), as is a reasonable expectation, then its
> possible to quickly exceed the total amount of pinnable memory.
>
> At which point we _should_ start failing fork(), which is a somewhat
> unexpected, and undesirable side-effect.

I'm not sure I see why we should fail fork() when we run out of pinned
memory.

> Ideally we'd unpin the old buffers and repin the new buffers on context
> switch, but that's impossible since faulting needs scheduling,
> recursion, we loose.

Or we can have per-cpu buffers for all user's tasks, record where each
task starts and ends in each buffer and cut out only bits relevant to
the task(s) that dump core.

Regards,
--
Alex

[toc] | [prev] | [next] | [standalone]

#1491166

On Mon, Sep 26, 2016 at 11:27:08AM +0300, Alexander Shishkin wrote:
> Peter Zijlstra <peterz@infradead.org> writes:
> 
> > Well, we could 'force' inject a VMA into the process's address space, we
> > do that for a few other things as well. It also makes for less
> > exceptions with the actual core dumping.
> 
> Threads then will end up with the same buffer (through sharing the mm),
> but they can't really share trace buffers.
> 
> Also, system core dump is still a problem.

Hurm, true on both counts.

> > But the worry I have is the total amount of pinned memory. If you want
> > to inherit this on fork(), as is a reasonable expectation, then its
> > possible to quickly exceed the total amount of pinnable memory.
> >
> > At which point we _should_ start failing fork(), which is a somewhat
> > unexpected, and undesirable side-effect.
> 
> I'm not sure I see why we should fail fork() when we run out of pinned
> memory.

Well, we cannot fully honour the inherit, what other option do we have?
Silently malfunctioning? That's far worse.

> > Ideally we'd unpin the old buffers and repin the new buffers on context
> > switch, but that's impossible since faulting needs scheduling,
> > recursion, we loose.
> 
> Or we can have per-cpu buffers for all user's tasks, record where each
> task starts and ends in each buffer and cut out only bits relevant to
> the task(s) that dump core.

Which gets you the problem that when a task dumps core there might not
be any state in the buffer, because the previous task flushed it all out
:/

[toc] | [prev] | [next] | [standalone]

#1491277 — Re: [RFC PATCH 1/6] perf: Move mlock accounting to ring buffer allocation

Peter Zijlstra <peterz@infradead.org> writes:

> On Mon, Sep 26, 2016 at 11:27:08AM +0300, Alexander Shishkin wrote:
>> Peter Zijlstra <peterz@infradead.org> writes:
>> > At which point we _should_ start failing fork(), which is a somewhat
>> > unexpected, and undesirable side-effect.
>> 
>> I'm not sure I see why we should fail fork() when we run out of pinned
>> memory.
>
> Well, we cannot fully honour the inherit, what other option do we have?
> Silently malfunctioning? That's far worse.

We can still put a note there saying that we tried. The user will know
to adjust their buffer size requirement or the RLIMIT_MEMLOCK.

>> > Ideally we'd unpin the old buffers and repin the new buffers on context
>> > switch, but that's impossible since faulting needs scheduling,
>> > recursion, we loose.
>> 
>> Or we can have per-cpu buffers for all user's tasks, record where each
>> task starts and ends in each buffer and cut out only bits relevant to
>> the task(s) that dump core.
>
> Which gets you the problem that when a task dumps core there might not
> be any state in the buffer, because the previous task flushed it all out
> :/

Well, there's going to be at list something that leads up to the core
dump if this task is the last one to schedule in for this buffer. It's a
bit more gambling, though.

Regards,
--
Alex

[toc] | [prev] | [next] | [standalone]

#1491401 — Re: [RFC PATCH 1/6] perf: Move mlock accounting to ring buffer allocation

Peter Zijlstra <peterz@infradead.org> writes:

> On Mon, Sep 26, 2016 at 11:27:08AM +0300, Alexander Shishkin wrote:
>> Peter Zijlstra <peterz@infradead.org> writes:
>> 
>> > Well, we could 'force' inject a VMA into the process's address space, we
>> > do that for a few other things as well. It also makes for less
>> > exceptions with the actual core dumping.
>> 
>> Threads then will end up with the same buffer (through sharing the mm),
>> but they can't really share trace buffers.
>> 
>> Also, system core dump is still a problem.
>
> Hurm, true on both counts.

OTOH, system core dump buffers don't need inheritance or memlock
accounting.

>> Or we can have per-cpu buffers for all user's tasks, record where each
>> task starts and ends in each buffer and cut out only bits relevant to
>> the task(s) that dump core.
>
> Which gets you the problem that when a task dumps core there might not
> be any state in the buffer, because the previous task flushed it all out
> :/

And also won't work with PMUs that don't generate PMIs, like ETMs.

Regards,
--
Alex

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web