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
Date: Tue, 11 Aug 2020 12:47:24 +0300 [thread overview]
Message-ID: <87364t1plf.fsf@ashishki-desk.ger.corp.intel.com> (raw)
In-Reply-To: <20200810144518.GB1448395@tassilo.jf.intel.com>
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
next prev parent reply other threads:[~2020-08-11 9:47 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-07-08 15:16 [PATCH 0/2] perf: Allow closing siblings' file descriptors Alexander Shishkin
2020-07-08 15:16 ` [PATCH 1/2] perf: Add closing sibling events' " Alexander Shishkin
2020-08-06 8:35 ` peterz
2020-08-06 15:32 ` Andi Kleen
2020-08-10 13:57 ` Alexander Shishkin
2020-08-10 14:45 ` Andi Kleen
2020-08-10 20:36 ` Peter Zijlstra
2020-08-11 8:12 ` Alexey Budankov
2020-08-11 14:29 ` Andi Kleen
2020-08-11 14:47 ` David Laight
2020-08-11 18:03 ` Andi Kleen
2020-08-11 21:06 ` David Laight
2020-08-11 9:47 ` Alexander Shishkin [this message]
2020-08-11 14:34 ` Andi Kleen
2020-08-11 16:21 ` Alexander Shishkin
2020-08-11 18:02 ` Andi Kleen
2020-07-08 15:16 ` [PATCH 2/2] perf record: Support closing siblings' " Alexander Shishkin
2020-07-08 21:09 ` Jiri Olsa
2020-07-16 8:42 ` [perf record] d65f0cbbc6: perf-sanity-tests.Setup_struct_perf_event_attr.fail kernel test robot
2020-07-09 8:30 ` [PATCH 0/2] perf: Allow closing siblings' file descriptors Alexey Budankov
2020-08-06 6:15 ` Adrian Hunter
2020-08-06 8:37 ` peterz
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=87364t1plf.fsf@ashishki-desk.ger.corp.intel.com \
--to=alexander.shishkin@linux.intel.com \
--cc=acme@redhat.com \
--cc=adrian.hunter@intel.com \
--cc=ak@linux.intel.com \
--cc=alexey.budankov@linux.intel.com \
--cc=jolsa@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=peterz@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.