Re: [RFC PATCH 1/6] perf: Move mlock accounting to ring buffer allocation
From: Alexander Shishkin
Date: Mon Sep 26 2016 - 08:40:35 EST
Peter Zijlstra <peterz@xxxxxxxxxxxxx> writes:
> On Mon, Sep 26, 2016 at 11:27:08AM +0300, Alexander Shishkin wrote:
>> Peter Zijlstra <peterz@xxxxxxxxxxxxx> 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
> 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.