lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87lgkotrwl.fsf@ashishki-desk.ger.corp.intel.com>
Date:   Fri, 06 Oct 2017 14:52:26 +0300
From:   Alexander Shishkin <alexander.shishkin@...ux.intel.com>
To:     Peter Zijlstra <peterz@...radead.org>
Cc:     Ingo Molnar <mingo@...hat.com>, linux-kernel@...r.kernel.org,
        acme@...hat.com, kirill.shutemov@...ux.intel.com,
        Borislav Petkov <bp@...en8.de>, rric@...nel.org
Subject: Re: [RFC PATCH 09/17] perf: Use shmemfs pages for userspace-only per-thread detached events

Peter Zijlstra <peterz@...radead.org> writes:

> On Tue, Sep 05, 2017 at 04:30:18PM +0300, Alexander Shishkin wrote:
>> In order to work around the problem of using up mlocked memory for the
>> detached events, we can pin the ring buffer pages only while they are
>> in use (that is, the event is ACTIVE), and unpin them for the rest of
>> the time. When not pinned in, these pages can be swapped out. This way,
>> one user can have at most mlock_limit*nr_cpus kB of memory pinned at
>> any given moment, however many events they actually have.
>> 
>> This enforces a constraint: pinning and unpinning may sleep and thus
>> can't be done in the event scheduling path. Instead, we use a task
>> work to do this, which this pattern us to userspace-only events.
>> Also, since one userspace thread only needs one buffer (for whatever
>> CPU it's running on at any given moment), we only do this for per-thread
>> events.
>> 
>> The source for such swappable pages is shmemfs. This patch allows
>> allocating perf ring buffer pages from an shmemfs file if the above
>> constraints are met.
>
> Right, so why still allow that previous icky thing? What cases do we
> need that for?

8/17..12/17 are really one patch split into smaller chunks. The first
one does the icky thing and then we get to what we actually want.

The idea is that you won't be able to enable inheritance for detached
events unless they are shmem-backed.

Regards,
--
Alex

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ