On Tue, Aug 11, 2020 at 12:47:24PM +0300, Alexander Shishkin wrote: > Andi Kleen <a...@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
