Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
IronPort-SDR: RWGSq/DlbdSV5jc4qXTRNpzilnDbVnr5Brc3ubAJl6BLBJ7i2yPkIExzcVAef9RHWKdGJwRsDc
 pGAAlFRHnDlw==
IronPort-SDR: 7pAq3sgAPjEfge61/OgB2MIbTTf7TPURc6xbnHMi/fzX63ICJvi+55iMIoZMat77zfKrQl37bk
 iF88IMUbsMvQ==
From:   Alexander Shishkin <alexander.shishkin@linux.intel.com>
To:     Andi Kleen <ak@linux.intel.com>
Cc:     peterz@infradead.org, Arnaldo Carvalho de Melo <acme@redhat.com>,
        Ingo Molnar <mingo@redhat.com>, linux-kernel@vger.kernel.org,
        Jiri Olsa <jolsa@kernel.org>, alexey.budankov@linux.intel.com,
        adrian.hunter@intel.com, alexander.shishkin@linux.intel.com
Subject: Re: [PATCH 1/2] perf: Add closing sibling events' file descriptors
In-Reply-To: <20200810144518.GB1448395@tassilo.jf.intel.com>
References: <20200708151635.81239-1-alexander.shishkin@linux.intel.com> <20200708151635.81239-2-alexander.shishkin@linux.intel.com> <20200806083530.GV2674@hirez.programming.kicks-ass.net> <20200806153205.GA1448395@tassilo.jf.intel.com> <875z9q1u3g.fsf@ashishki-desk.ger.corp.intel.com> <20200810144518.GB1448395@tassilo.jf.intel.com>
Date:   Tue, 11 Aug 2020 12:47:24 +0300
Message-ID: <87364t1plf.fsf@ashishki-desk.ger.corp.intel.com>
MIME-Version: 1.0
Content-Type: text/plain
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

Andi Kleen <ak@linux.intel.com> writes:

>> It didn't. I can't figure out what to charge on the locked memory, as
>> all that memory is in kernel-side objects. It also needs to make sense
>
> I don't see how that makes a difference for the count. It just account
> bytes. Can you elaborate?

Right, but which bytes? One byte per event? That's
arbitrary. sizeof(struct perf_event)? Then, probably also sizeof(struct
perf_event_context).

>> as iirc the default MLOCK_LIMIT is quite low, you'd hit it sooner than
>> the file descriptor limit.
>
> For a single process? 

The above two structs add up to 2288 bytes on my local build. Given the
default RLIMIT_MEMLOCK of 64k, that's 28 events. As opposed to ~1k
events if we keep using the RLIMIT_NOFILE. Unless I'm missing your
point.

Regards,
--
Alex