Messages in this thread | | | Date | Tue, 11 Aug 2020 07:34:24 -0700 | From | Andi Kleen <> | Subject | Re: [PATCH 1/2] perf: Add closing sibling events' file descriptors |
| |
On Tue, Aug 11, 2020 at 12:47:24PM +0300, Alexander Shishkin wrote: > 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).
Yes the sum of all the sizeofs needed for a perf_event.
> > >> 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.
Yes that's true. We would probably need to increase the limit to a few MB at least.
Or maybe use some combination with the old rlimit for compatibility. The old rlimit would give an implicit extra RLIMIT_NFILE * 2288 limit for RLIMIT_MEMLOCK. This would only give full compatibility for a single perf process, but I suspect that's good enough for most users.
-Andi
| |